Что говорить о новичках, если даже опытные пользователи не знают, что такое технология S.M.A.R.T. и зачем она нужна для жестких дисков.
Данная статья для тех, кто хотел бы узнать больше о жестких дисках, о том внешний или внутренний жесткий диск к компьютеру и должна ли быть включена технология S.M.A.R.T.

Для чего нужна технология S.M.A.R.T.

Люди всегда во все времена пытались сохранить информацию, уберечь её, понимали, что без знаний нельзя существовать, неся гордое знамя человека. С появлением первых компьютеров и соответственно с появления первых носителей информации товарищи, ответственные за прогресс, начали морщить лбы над проблемой надёжности хранения данных. Предлагалась масса методик, но дожила до наших дней одна, воплотив в себе некоторые – технология S.M.A.R.T. (Self Monitoring analysis and reporting technology — технология самонаблюдения, анализа и оповещения ).
Родилось сие в недрах серверных технологий компании IBM в далёком 1992 году. Следует заметить, что большая часть идей перед их воплощением в массе прошла обкатку в первую очередь на промышленных серверах. Компьютерным прогрессом правит бизнес.

Как это работает

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

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

Недостатки

1. К сожалению, «саморемап» происходит довольно редко, дело в том, что процедура сия, как правило, срабатывает во время записи, но в силу того, что ОС перед записью информации производит верификацию (сравниваются контрольные суммы), то при обнаружении сбоя, ОС просто игнорирует сектор. Возможно, разработчики S.M.A.R.T. наконец-то договорятся с разработчиками ОС, но дело это будущего.

2. Оповещение в случае ошибок также откровенно «сыровато». Существует так называемый «общий» статус S.M.A.R.T. Он возникает как результат самоанализа всех параметров (журналирование основных статусов работы). Для его генерации необходима поддержка проверки статуса S.M.A.R.T. со стороны внешнего контроллера, к которому «цепляются» харды (зачастую это материнская плата). Вся соль в том, что в большинстве Bios материнок это опция по умолчанию отключена, ибо включение чревато массой «глюков». Чья тут недоработка сказать сложно, но «во избежание», производители отключают автопроверку статуса S.M.A.R.T. Исключения видел лишь на материнских платах Asus, причём работало всё достаточно стабильно. Потому для просмотра статуса и параметров (атрибутов) S.M.A.R.T. зачастую необходимы сторонние программы. Большинство программ диагностики жёстких дисков позволяют это сделать.

Стоит ли пользоваться

По ходу анализа состояния S.M.A.R.T. может возникнуть вопрос доверия, стоит ли полагаться на данные этой чудо-технологии. Я думаю — стоит. Ибо за отсутствием лучших альтернатив выбираем те, что есть.

Поискал процент отказов, нашёл интересную цифру. Дескать, в 60 процентов случаев эта технология позволяла предсказать отказ жёсткого диска.
Что ж, вполне возможно. Но, я надеюсь, как вы поняли из всего выше написанного, что спасение утопающих дело рук самих утопающих.
Если вы хотите видеть свои данные целыми, то регулярно, самостоятельно производите анализ вашего хранилища данных.
Автор статьи «Что такое S.M.A.R.T. у жестких дисков»: timoffeyy

Что такое S.M.A.R.T

S.M.A.R.T. (Self-Monitoring Analysis and Reporting Technology) - технология самослежения и предупреждения (Технология Самодиагностики, Анализа и Отчета) позволяет отслеживать и предсказывать возникновение ошибок, связанных с функционированием HDD, следовательно появляется возможность вовремя сделать резервную копию данных, тем самым избежать морального и материального ущерба от потери информации.

S.M.A.R.T. - это набор программ, записанных в микрокод винчестера.

Каждая фирма-производитель дисков ведет свои разработки, отсюда и разнообразие параметров для разных дисков. Однако существуют общие параметры.

Использование технологии S.M.A.R.T. невозможно без наличия следующих двух составляющих: ПО, встроенного в контроллер накопителя и внешнего ПО, встроенного в хост.

История возникновения S.M.A.R.T. технологий

винчестер атрибут технология сектор

На заре развития ПК жесткие диски подключались к достаточно сложным и дорогим контроллерам (данные от диска поступали в аналоговом виде), часто диск и контроллер "понимали" только друг друга. Покупка жесткого диска требовала покупки, установки и настройки контроллера (у которого даже был свой BIOS). В целях исправления такой ситуации было решено (в 1986 году) перенести управляющую логику на плату, непосредственно прикрепляемую к жесткому диску (т.е. "встроить электронику"), а со стороны компьютера оставить достаточно простой хост-контроллер. Благодаря этому система не должна знать ничего о реальных физических параметрах (геометрии, кодировании информации и пр.) диска, подключенного к ней, чтобы успешно с ним работать. Кроме того, производитель диска может спокойно расширять существующие и встраивать новые технологии, не опасаясь потерять совместимость с немного устаревшими системами (в случае с UltraDMA дело в изменении протокола обмена с хост-контроллером, так что это - исключение). К последним относится технология S.M.A.R.T.

S.M.A.R.T. - открытая технология, разработанная фирмой Compaq не для жестких дисков, а для "интеллектуальных" компьютерных устройств. В применении к жестким дискам S.M.A.R.T. была реализована фирмой Quantum в 1995 году, в дальнейшем была поддержана в разработках крупнейшими мировыми производителями жестких дисков - Seagate Technology, IBM, Conner Peripherials, Western Digital и Quantum.. Суть S.M.A.R.T. технологии заключается в том, что винчестер сам аппаратно отслеживает состояние своей работоспособности и способен заранее предупредить пользователя о своем предаварийном состоянии.

Предложенная IBM технология предсказания надежности называется PFA (Predictive Failure Analysis). Она заключается в измерении нескольких параметров, включая высоту полета головок над поверхностью дисковых пластин, чтобы предсказать приближающийся сбой. Дисковые накопители, почувствовав ухудшение (деградацию) параметров своей работы, таких как упомянутая высота полета головок, изменяют технологические параметры доступные для считывания и анализа программой SMART HDD, которая в свою очередь уведомляет пользователя о надвигающемся сбое. Измерялось несколько ключевых параметров, и их оценка велась непосредственно в firmware диска. Результат был ограничен одним битом: либо хорошо, либо значение тестируемого параметра сомнительное и может скоро привести диск к выходу из строя. После получения предупреждения пользователи получают возможность предпринять действия, необходимые для обеспечения безопасности своих данных. Немногим позже корпорация Compaq сообщила о революционной разработке в области диагностики, названной IntelliSafe. Эта технология, разработанная при участии Seagate, Quantum и Conner, отслеживает множество показателей и посылает управляющей программе информацию о пороге опасности. Дисковый накопитель затем решает, насколько вероятен сбой и в свою очередь передает сообщение системе вместе с вызвавшим тревогу показателем и пороговым значением. Показатели и пороговые значения, реализованные в

IntelliSafe, варьируются для жестких дисков каждого производителя, но интерфейс и способ, которым сообщения передаются хост-системе, общие для всех. Compaq постаралась сделать IntelliSafe общедоступной, представив свои спецификации для вычислительной среды IDE/АТА (документ SFF-8035) в мае 1995 года комитету Small Form Factor Commitee. Компания Seagate быстро определила, что технология предсказания надежности сулит громадные выгоды пользователям, и исследовала возможность сделать версию, доступную другим системным ОЕМ - производителям, интеграторам и независимым производителям программного обеспечения. В разработке этой новой версии она объединилась с фирмами Conner, IBM, Quantum и Western Digital. В результате их сотрудничества и появилась технология S.M.A.R.T., в которой сочетаются концептуальные элементы IntelliSafe от Compaq и PFA от IBM. Возможности S.M.A.R.T. охватывают целые серии показателей, или атрибутов диагностики, подбираемые специально для каждой модели накопителя. Индивидуальный подход при выборе атрибутов очень важен, поскольку архитектура жестких дисков изменяется от модели к модели. Показатели и пороговые значения, которые определяют предсбойное состояние для одной модели, могут ничего не означать для другого винчестера. Другими словами, архитектура привода определяет, какие показатели надлежит измерять и при переходе какого порогового значения стоит бить тревогу. Хотя не все сбои можно предсказать, следует ожидать развития S.M.A.R.T. как технологии по мере накопления опыта в точном предсказании надежности. Постоянные изменения показателей и их значений, связанные с развитием дисковых технологий, также приводят к необходимости индивидуальной настройки и могут послужить основой для улучшения самой технологии предсказания.

Дисковые накопители должны быть способны отслеживать множество

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

Непредсказуемые сбои происходят быстро, как в случае проблем с электроникой или механикой привода, таких, например, как бросок напряжения питания, который может повредить чипы или даже схему в целом. Повышение качества, совершенствование конструкции, технологии и производства могут уменьшить вероятность непредсказуемых аварий. Предсказуемые сбои характеризуются деградацией того или иного параметра с течением времени, прежде чем диск выйдет из строя. Это создает возможность выбора показателей, которые можно отслеживать, чтобы на базе их анализа предсказать сбои. Многие механические сбои обычно расцениваются как предсказуемые, такие, например, как деградация высоты полета головок, которая говорит о возможности повреждения поверхности дисков. Некоторые электронные сбои можно отследить по деградации атрибутов, прежде чем они наступят, но чаще именно механические проблемы являются постепенно нарастающими и предсказуемыми. S.M.A.R.T. предупреждает, что стоит заняться процедурой резервирования, и сохраняет в целости пользовательские данные. Механические сбои, которые в основном являются предсказуемыми, составляют около 60 процентов от всех дисковых сбоев. Это число важно, поскольку показывает большие возможности использования технологий предсказания надежности. С развитием технологии S.M.A.R.T. все большее число сбоев становится предсказуемым и попадает в поле ее ответственности, а вероятность потери данных уменьшается.

Более 50% трафика во всем мире обслуживает технология связки Apache и Nginx – веб сервера, которые имеют открытый исходный код. Nginx исполняет функцию фронтэнда, Apache – бэкэнда . Nginx первым принимает запросы пользователей и выдает по ним необходимый контент – изображения, файлы, скрипты. Тяжелый Apache в свою очередь не имеет с этим дело, а обрабатывает динамику. Nginx проксирует запросы и возвращает ответы . Данная связка отлично подходит для больших сайтов, которые посещают много пользователей. Для маленьких сайтов данная связка не даст роста производительности. Apache и Nginx снижает нагрузку на сервер в общем, благодаря тому, что Nginx обрабатывает статический контент, а Apache динамический.

Apache и Nginx не нужно рассматривать как взаимозаменяемые технологии, не смотря и на то, что они имеют множество схожих функций. Каждый из веб серверов имеет свои достоинства и его применение зависит от поставленной задачи. В данной статье рассмотрим каждую технологию в зависимости от сферы применения. Статья будет полезна собственникам виртуального и выделенного физического сервера.

Функциональный и быстрый Nginx был выпущен в 2004 году и после этого релиза начал набирать свою популярность. Благодаря своей легкости и масштабируемости хорошо работает на любом оборудовании. Nginx используют в двух направлениях: как веб сервер или как прокси.

Что делает Nginx в качестве веб сервера?

автоматически создает кэш дескрипторы и списки файлов, обслуживает индексные файлы и статические запросы;
ускоряет отказоустойчивость, проксирование и рапределение нагрузки;
кэширует при FastCGI и ускоряет проксирование;
поддерживает SSL;
поддерживает Perl;
имеет филтры и модульность;
аунтифецирует HTTP и фильтрирует SSL.

В качестве прокси Nginx:

полное обеспечение StartTLS и SSL;
легкость аутентификации (USER/PASS, LOGIN);
использует внешний HTTP-сервер для перенаправления на POP3/IMAP-бэкенд.

Как видим, Nginx выполняет множество функций, при этом не перегружая систему. По официальным данным, технологию используют более 56 млн. сайтов во всем мире (к примеру, Rambler, Yandex, Mail, Begun, WordPress.com, vk.com, Facebook, Rutracker.org), но по популярности Nginx уступает Apache. Почему же так популярен Apache?

Веб сервер Apache – кросплатформенное программное обеспечение, которое было создано в 1995 году. Благодаря большой документации и хорошей интеграции с сторонним ПО, Apache получил огромное распространение. Поддерживает следущие ОС – Linux, BSD, Mac OS, Microsoft Windows, Novell NetWare, BeOS. .

Преимущества веб сервера Apache:

поддержка языков программирования PHP, Python, Ruby, Perl, ASP, Tcl ;
легкость в подключении внешних модулей;
поддержка технологий CGI и FastCGI ;
наличие механизмов, которые обеспечивают безопасноть и разграничение к доступу данных;
возможность использовать СУБД для аутентификации пользователей;
гибкая и надежная конфигурация системы;
подходит для приложений, которым нужна мощная криптографическая защита данных ;
возможность создания пользовательских директорий для веб-сайта;
возможность настройки виртуальных хостов , с помощью которых на одном физическом сервере можно создать несколько виртуальных;
ведет протоколы того, что происходит на вашем сервере;
активная обратная связь с разработчиками и своевременное решения возникших ошибок в ПО.

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

Хотите обезопасить работу PHP на сервере? Об этом более подробно .

После ознакомления с плюсами и минусами Apache и Nginx, Вы можете выбрать полезное решения для своего сайта в зависимости от целей, которые преследуете. Но возможно Вам понадобится именно связка Apache+Nginx для достижения наилучшего результата. Например, часто используют Nginx перед Apache в качестве реверс прокси. Такая комбинация позволяет обрабатывать много конкурентных запросов и сортирует их. Те запросы, которые не под силу Nginx отправляются к Apache, тем самым снижается нагрузка на последний. Отказоустойчивость в таком случае увеличивается. Перед выбором веб сервера нужно провести обязательные тесты на производительность и возможности каждого решения.

Обо всех технологиях, которые поддерживает хостинг HyperHost, более подробно по .

Данная статья была предоставлена для общего ознакомления с возможностями связки веб серверов Apache и Nginx. Еще больше информации в .

Если понадобится наша помощь, обращайтесь!

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

17247 раз(а) 8 Сегодня просмотрено раз(а)

Nginx – это популярный и производительный веб-сервер и обратный прокси-сервер.

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

Примечание : Руководство выполнено на Ubuntu 12.04.

Иерархия каталогов Nginx

Nginx хранит конфигурационные файлы в каталоге /etc/nginx.

В этом каталоге находится ещё несколько каталогов и модульных конфигурационных файлов.

cd /etc/nginx
ls -F

conf.d/ koi-win naxsi.rules scgi_params uwsgi_params
fastcgi_params mime.types nginx.conf sites-available/ win-utf
koi-utf naxsi_core.rules proxy_params sites-enabled/

Пользователи Apache уже знакомы с каталогами sites-available и sites-enabled. Эти каталоги определяют конфигурации сайтов. Файлы обычно создаются и хранятся в sites-available; в sites-enabled хранятся только конфигурации включенных сайтов. Для этого нужно создать символическую ссылку из sites-available в sites-enabled.

Каталог conf.d тоже можно использовать для хранения конфигураций. Каждый файл с расширением.conf будет читаться при запуске Nginx. Синтаксис таких файлов не должен содержать ошибок.

Почти все оставшиеся файлы хранятся в /etc/nginx, который содержит сведения о конфигурации конкретных процессов или дополнительных компонентов.

Главным конфигурационным файлом Nginx является nginx.conf.

Файл nginx.conf

Файл nginx.conf читает соответствующие конфигурационные файлы и объединяет их в единый файл конфигурации при запуске сервера.

Откройте файл:

sudo nano /etc/nginx/nginx.conf

user www-data;
worker_processes 4;
pid /var/run/nginx.pid;
events {
worker_connections 768;
# multi_accept on;
}
http {
. . .

Первые строки задают общие сведения о Nginx. Строка user www-data указывает пользователя, с помощью которого запускается сервер.

Директива pid указывает, где будут храниться PID процессов для внутреннего использования. Строка worker_processes определяет количество процессов, которое может одновременно поддерживать Nginx.

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

За общими сведениями о сервере следует раздел events. Он управляет обработкой соединений Nginx. За ним идёт блок http. Прежде чем продолжить ознакомление с конфигурациями веб-сервера, нужно понять, как отформатирован конфигурационный файл Nginx.

Структура конфигурационного файла Nginx

Конфигурационный файл Nginx делится на блоки.

Первый блок – events, за ним идёт http и начинается главная иерархия конфигураций.

Детали конфигурации блока http делятся на уровни при помощи закрытых блоков, которые наследуют свойства из блока, в котором они расположены. В блоке http хранится большая часть общих конфигураций Nginx, которые делятся на блоки server, которые, в свою очередь, делятся на блоки location.

Во время настройки Nginx важно помнить следующее правило: чем выше уровень конфигурации, тем больше блоков наследует эту конфигурацию; чем ниже уровень конфигурации, тем она «индивидуальнее». То есть, если параметр Х должен применяться в каждом блоке server, то такой параметр нужно поместить в блок http.

Если вы внимательно рассмотрите файл, вы заметите, что он содержит много опций, которые определяют поведение программы как единого целого.

Например, чтобы настроить сжатие файлов, нужно установить такие параметры:

gzip on;
gzip_disable "msie6";

Это включит поддержку gzip для сжатия отправляемых клиенту данных и отключит gzip для Internet Explorer 6 (поскольку этот браузер не поддерживает сжатия данных).

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

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

Блок http в файле nginx.conf заканчивается так:

include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;

Это говорит о том, что блоки server и location, которые определяют настройки конкретных сайтов и URL-адресов, будут храниться за пределами этого файла.

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

Закройте файл nginx.conf. Теперь нужно изучить настройки отдельных сайтов.

Виртуальные блоки Nginx

Блоки server в Nginx являются аналогом виртуальных хостов Apache (но для удобства их тоже принято называть виртуальными хостами). По сути, блоки server – это технические характеристики отдельных веб-сайтов, размещённых на одном сервере.

В каталоге sites-available можно найти файл блока server по умолчанию, который поставляется вместе с сервером. Этот файл содержит все необходимые данные для обслуживания сайта.

cd sites-available
sudo nano default

root /usr/share/nginx/www;
index index.html index.htm;
server_name localhost;
location / {

}
location /doc/ {

alias /usr/share/doc/;
autoindex on;
allow 127.0.0.1;
deny all;

Файл по умолчанию очень хорошо закомментирован, но в примере выше комментарии опущены для простоты и удобства.

Блок server включает в себя все настройки, помещённые между фигурными скобками:

server {
. . .
}

Этот блок размещён в файле nginx.conf ближе к концу блока http с помощью директивы include.

Директива root определяет каталог, в котором будет храниться контент сайта. В этом каталоге Nginx будет искать запрашиваемые пользователем файлы. По умолчанию это каталог /usr/share/nginx/www.

Обратите внимание: все строки заканчиваются точкой с запятой. Так Nginx отделяет одну директиву от другой. Если точки с запятой не будет, Nginx прочитает две директивы (или несколько директив) как одну директиву с дополнительными аргументами.

Директива index определяет файлы, которые будут использоваться в качестве индекса. Веб-сервер будет проверять файлы в порядке их перечисления. Если ни одна страница не была запрошена, блок server найдёт и вернёт файл index.html. Если он не сможет найти этот файл, он попытается обработать index.htm.

Директива server_name

Директива server_name содержит список доменных имен, которые будут обслуживаться этим блоком server. Количество доменов неограниченно; домены в списке следует разделять пробелами.

Символ звёздочки (*) в начале или конце домена задаёт имя с маской, где звёздочка соответствует части (или нескольким частям) имени. Например, имя *.example.com будет соответствовать именам forum.example.com и www.animals.example.com.

Если запрашиваемый url-адрес соответствует нескольким директивам server_name, он сначала ответит той, с которой совпадает полностью.

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

Имена сервера, которые используют регулярные выражения, начинаются с тильды (~). К сожалению, данная тема выходит за рамки данной статьи.

Блоки location

Строка location / указывает, что директивы в скобках будут применяться ко всем запрашиваемым ресурсам, которые не соответствуют никаким другим блокам location.

Такие блоки могут содержать uri путь (например /doc/). Чтобы установить полное соответствие между location и uri, используется символ =. Символ ~ устанавливает соответствие с регулярными выражениями.

Тильда включает чувствительный к регистру режим, а тильда со звёздочкой – регистронезависимый режим.

Если запрос полностью соответствует блоку location, то сервер останавливает поиск и использует такой блок. Если сервер не находит полностью подходящего блока location, он сравнивает URI с параметрами директив location. Nginx выберет блок, в котором используется сочетание символов ^~ и который совпадает с URI.

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

В качестве заключения следует отметить, что Nginx предпочитает точные соответствия. Если таких соответствий нет, он ищет регулярное выражение, а затем выполняет поиск по URI. Чтобы изменить приоритетность поиска по URI, используйте комбинацию символов ^~.

Директива try_files

Директива try_files – очень полезный инструмент, который проверяет наличие файлов в заданном порядке и использует первый найденный файл для обработки запроса.

Это позволяет вам с помощью дополнительных параметров определить, как Nginx будет обслуживать запросы.

В конфигурационном файле по умолчанию есть строка:

try_files $uri $uri/ /index.html;

Это значит, что при поступлении запроса, обслуживаемого блоком location, Nginx сначала попробует обслужить uri как файл (такое поведение задаёт переменная $uri).

Если сервер не обнаруживает соответствия переменной $uri, он попробует использовать uri как каталог.

С помощью слэша в конце сервер проверяет существование каталога, например, $uri/.

Если ни один файл или каталог не найден, Nginx выполняет файл по умолчанию (в данном случае это index.html в root-каталоге блока server). Каждая директива try_files использует последний параметр в качестве запасного варианта, потому этот файл должен существовать в системе.

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

Например, если блок location / не может найти запрашиваемый ресурс, вместо файла index.html он может вернуть ошибку 404:

try_files $uri $uri/ =404;

Для этого нужно поставить знак равно и задать код ошибки в качестве последнего параметра (=404).

Дополнительные параметры

Директива alias позволяет Nginx обслуживать страницы блока location вне заданного каталога (например, вне root).

Например, файлы, запрашиваемые в /doc/, будут обслужены из /usr/share/doc/.

Директива autoindex on позволяет включает листинг директорий Nginx для заданной директивы location.

Строки allow и deny управляют доступом к каталогам.

Заключение

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

Разобравшись с конфигурациями Nginx и научившись работать с ними, вы получите все преимущества этого мощного и легковесного инструмента.

Tags: ,

Nginx – это веб-сервер вкупе с почтовым прокси-сервером, публично доступный с 2004 года. Разработка проекта началась в 2002 году, по-русски название звучит как энджин-экс. Будучи творением рук известного программиста, Игоря Сысоева, первоначально Nginx предназначался для компании Rambler. Он рассчитан на операционные системы, относящиеся к группе Unix-подобных. Сборка успешно тестировалась на OpenBSD, FreeBSD, Linux, Mac OS X, Solaris. На платформе Microsoft Windows Nginx стал работать с появлением бинарной сборки версии 0,7.52.

Статистика за март 2011 года свидетельствует, что количество сайтов, обслуживаемых Nginx, уже перешагнуло отметку в 22 миллиона. Сегодня Nginx используют такие известные проекты, как Rambler, Begun, Yandex, SourceForge.net, WordPress.com, vkontakte.ru и другие. Наряду с lighttpd, Nginx применяют для выдачи статичного контента, генерируемого «неудобным» веб-приложением, функционирующим «под началом» другого веб-сервера.
Но прежде чем углубляться в дебри функциональных особенностей Nginx – нелишним будет вспомнить, что такое веб-сервер вообще и прокси-сервер в частности.

Веб-сервер и прокси-сервер

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

В перечень дополнительных функций веб-серверов входит: авторизация и аутентификация пользователей, ведение журнала их обращений к ресурсам, поддержка HTTPS для защищённости коммутирования с клиентами и другие. Наиболее часто применяемым в Unix-подобных ОС веб-сервером является Apache. Третью строчку в списке клиентских предпочтений в настоящее время занимает Nginx.

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

Самым простым прокси-сервером считается Network Address Translator или NAT. В 2000 году прокси-NAT был встроен в дистрибутив Windows. Прокси-серверы, как и любое явление, имеют две стороны медали, то есть могут быть использованы как во благо, так и во зло. Например, с их помощью скрывают свои IP-адреса те, кто опасается санкций за свои неблаговидные действия в сети…

Функциональный ряд Nginx:

серверное обслуживание индексных файлов, статичных запросов, генерирование дескрипторов кэш открытых файлов, списка файлов;
акселерированное проксирование, элементарное распределение нагрузки, отказоустойчивость;
поддержка кэширования в ходе акселерированного проксирования и FastCGI;
поддержка FastCGI (акселелированная) и memcached серверов;
модульность, фильтры, включая «докачку» (byte-ranges) и сжатие (gzip);
HTTP-аутентификация, chunked ответы, SSI-фильтр;
параллельное выполнение нескольких подзапросов на странице, обрабатываемых через FastCGI или прокси в SSI-фильтре;
поддержка StartTLS и SSL;
возможность поддержки встроенного Perl;
простая аутентификация (USER/PASS, LOGIN);
серверперенаправление (IMAP/POP3-прокси) пользователя на IMAP/POP3-бэкенд с применением внешнего сервера аутентификации (HTTP).

Для тех, кто не «на ты» с данной терминологией – описание функционала Nginx может показаться весьма туманным. Но когда речь пойдёт о способах конкретного использования этого веб-сервера – он понемногу начнёт развеиваться.

Архитектура и конфигурация

Рабочие процессы в Nginx одновременно обслуживают множество соединений, обеспечивая их вызовами ОС (операционной системы) epoll (Linux), select и kqueue (FreeBSD). Данные, полученные от клиента, разбираются посредством конечного автомата. Обработку разобранного запроса осуществляет цепочка модулей, задаваемая конфигурацией. Формирование ответа клиенту происходит в буферах, которые могут указывать на отрезок файла или хранить данные в памяти. Последовательность передачи данных клиенту определяется цепочками, в которые группируются буферы.

В структурном отношении HTTP-сервер Nginx разделён на виртуальные серверы, которые в свою очередь делятся на location. Виртуальному серверу или директиве можно задать порты и адреса для приёма соединений. Для location можно задать точный URI, часть URI, или регулярное выражение.Для оперативного управления памятью служат пулы, являющиеся последовательностью заранее выбранных блоков памяти. Один блок, выделяемый изначально под пул, имеет длину от 1 до 16 килобайт. Он разделён на области – занятую и незанятую. По мере заполнения последней выделение нового объекта обеспечивается образованием нового блока.

Географическая классификация клиентов по их IP-адресу производится в Nginx посредством специального модуля. Система Radix tree позволяет оперативно работать с IP-адресами, занимая минимум памяти.

Преимущества Nginx

Nginx считается очень быстрым HTTP сервером. Вместо Apache или совместно с ним Nginx используют, чтобы ускорить обработку запросов и уменьшить нагрузку на сервер. Дело в том, что огромные возможности, заложенные модульной архитектурой Apache, большинству пользователей не требуются. Платить же за эту невостребованную функциональность приходится значительным расходом системных ресурсов. Для обычных сайтов, как правило, характерно явное «засилье» статичных файлов (изображений, файлов стилей, JavaScript), а не скриптов. Никакого специального функционала для передачи этих файлов посетителю ресурса не требуется, так как задача весьма проста. А, значит, и веб-сервер для обработки таких запросов должен быть простым и легковесным, как Nginx.

Способы применения Nginx

На отдельном порту/IP. Если ресурс насыщен изображениями или файлами для скачивания Nginx можно настроить на отдельном порту или же IP и раздавать через него статичный контент. Для этого, правда, придётся немного повозиться со сменой ссылок на сайте. При большом количестве запросов к статичным файлам есть смысл завести отдельный сервер и поставить на него Nginx.

Акселерированное проксирование . При этом варианте все посетительские запросы поступают вначале к Nginx. Запросы на получение статичных файлов (например, картинки, простого HTML, JavaScript или CSS-файла) Nginx обрабатывает самостоятельно. В случае обращения пользователя к тому или иному скрипту он переадресует запрос в ведомство Apache. Никаких трансформаций с кодом сайта делать при этом не нужно.

Если канал от сервера к посетителю и наоборот грешит медлительностью – такое применение Nginx может дать дополнительный эффект. Полученный от посетителя запрос Nginx передаёт для обработки Apache. Обработав запрос, Apache направляет страницу Nginx и с чувством выполненного долга прекращает соединение. Отправлять пользователю страницу Nginx может теперь как угодно долго, практически не расходуя системных ресурсов. Работа Apache на его месте сопровождалась бы неоправданно высокой нагрузкой на память при работе практически вхолостую. Кстати, этот вариант использования Nginx имеет ещё одно название: «frontend к Apache» .

Nginx плюс FastCGI. Apache может вообще не понадобиться, если интерпретатор языка, на котором написаны скрипты сайта, поддерживает FastCGI-технологию. К таким языкам относятся, например, PHP, Perl и ряд других. Правда, в этом случае возможно придётся модифицировать коды скриптов.

О том, как установить и настроить Nginx в сети есть немало детальных материалов. Узнать о Nginx подробнее можно и на сайте его разработчика Игоря Сысоева.