Для чего нужен сервер, какие серверы бывают. Нетривиальные случаи работы с серверами В чем принцип работы сервера

Если ежедневно используется компьютер, который подключен к сети, если на мобильном гаджете тоже подключен Интернет, то каждый пользователь время от времени сталкивается со словом – «сервер». Причем это слово может встречаться в разных сочетаниях, и не каждый пользователь понимает, о чем идет речь. Что же скрывается до словом «сервер», да и зачем он пользователям нужен?

Под понятием «сервер» может скрываться аппаратное устройство и программное обеспечение для него (аппаратный и виртуальный). Аппаратный сервер – это отдельный компьютер. Он нужен для обеспечения работы других ПК и офисной техники. Виртуальный сервер – это ПО. При этом конкретный сервер объединяет эти два вида.

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

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

Поломка сервера или сбой в его работе может закончиться катастрофой

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

Сервер обеспечивает выход в Сеть. Все сайты хранятся на серверах. Это обеспечивает виртуальный хостинг. Такую услугу предоставляют хостинговые компании.

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

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

HTTP-сервер

На заре развития интернета сайты представляли собой простое хранилище специальным образом размеченных документов и некоторых связанных с ними данных: файлов, изображений и т.п. Для того, чтобы документы могли ссылаться друг на друга и связанные данные был предложен специальный язык гипертекстовой разметки HTML, а для доступа к таким документам посредством сети интернет протокол HTTP. И язык, и протокол, развиваясь и совершенствуясь, дожили до наших дней без существенных изменений. И только начавший приходить на смену принятому в 1999 году протоколу HTTP/1.1 протокол HTTP/2 несет кардинальные изменения с учетом требований современной сети.

Протокол HTTP реализован по клиент-серверной технологии и работает по принципу запрос-ответ без сохранения состояния. Целью запроса служит некий ресурс, который определяется единым идентификатором ресурса - URI (Uniform Resource Identifier ), HTTP использует одну из разновидностей URI - URL (Uniform Resource Locator ) - универсальный указатель ресурса , который помимо сведений о ресурсе определяет также его физическое местоположение.

Задача HTTP-сервера обработать запрос клиента и либо выдать ему требуемый ресурс, либо сообщить о невозможности это сделать. Рассмотрим следующую схему:

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

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

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

Сайты того времени вообще мало походили на современные, например, ниже показан вид одного из пионеров русскоязычного интернета, сайт компании Rambler:

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

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

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

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

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

CGI

Следующим шагом в развитии веб-технологии стало появление специальных программ (скриптов) выполняющих обработку запроса пользователей на стороне сервера. Чаще всего они пишутся на скриптовых языках, первоначально это был Perl, сегодня пальму лидерства удерживает PHP. Постепенно возник целый класс программ - системы управления контентом - CMS (Content management system ), которые представляют полноценные веб-приложения способные обеспечить динамическую обработку запросов пользователя.

Теперь важный момент: веб-сервера не умели и не умеют выполнять скрипты, их задача - отдача статического содержимого. Здесь на сцену выходит новая сущность - сервер приложений, который представляет собой интерпретатор скриптовых языков и с помощью которого работают написанные на них веб-приложения. Для хранения данных обычно используются СУБД, что обусловлено необходимостью доступа к большому количеству взаимосвязанной информации.

Однако сервер приложений не умеет работать с протоколом HTTP и обрабатывать пользовательские запросы, так как это задача веб-сервера. Чтобы обеспечить их взаимодействие был разработан общий интерфейс шлюза - CGI (Common Gateway Interface ).

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

Для передачи данных используются стандартные потоки ввода-вывода, от веб-сервера к СGI-приложению данные передаются через stdin , принимаются назад через stdout , для передачи сообщений об ошибках используется stderr .

Рассмотрим процесс работы такой системы подробнее. Получив запрос от браузера пользователя веб-сервер определяет, что запрошено динамическое содержимое и формирует специальный запрос, которой через интерфейс CGI направляет веб-приложению. При его получении приложение запускается и выполняет запрос, результатом которого служит HTML-код динамически сформированной страницы, который передается назад веб-серверу, после чего приложение завершает свою работу.

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

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

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

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

На текущий момент CGI практически не применяется, так как ему на смену пришли более совершенные технологии.

FastCGI

Как следует из названия, основной целью разработки данной технологии было повышение производительности CGI. Являясь ее дальнейшим развитием FastCGI представляет собой клиент-серверный протокол для взаимодействия веб-сервера и сервера приложений, обеспечивающий высокую производительность и безопасность.

FastCGI устраняет основную проблему CGI - повторный запуск процесса веб-приложения на каждый запрос, FastCGI процессы запущены постоянно, что позволяет существенно экономить время и ресурсы. Для передачи данных вместо стандартных потоков используются UNIX-сокеты или TCP/IP , что позволяет размещать веб-сервер и сервера приложений на разных хостах, таким образом обеспечивая масштабирование и/или высокую доступность системы.

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

Для управления FastCGI процессами и распределением нагрузки служат менеджеры процессов, они могут быть как частью веб-сервера, так и отдельными приложениями. Популярные веб-сервера Apache и Lighttpd имеют встроенные менеджеры FastCGI процессов, в то время как Nginx требует для своей работы c FastCGI внешний менеджер.

PHP-FPM и spawn-fcgi

Из внешних менеджеров для FastCGI процессов применяются PHP-FPM и spawn-fcgi. PHP-FPM первоначально был набором патчей к PHP от Андрея Нигматулина, решавший ряд вопросов управления FastCGI процессами, начиная с версии 5.3 является частью проекта и входит в поставку PHP. PHP-FPM умеет динамически управлять количеством процессов PHP в зависимости от нагрузки, перезагружать пулы без потери запросов, аварийный перезапуск сбойных процессов и представляет собой достаточно продвинутый менеджер.

Spawn-fcgi является частью проекта Lighttpd, но в состав одноименного веб-сервера не входит, по умолчанию Lighttpd использует собственный, более простой, менеджер процессов. Разработчики рекомендуют использовать его в случаях, когда вам нужно управлять FastCGI процессами расположенными на другом хосте, либо требуются расширенные настройки безопасности.

Внешние менеджеры позволяют изолировать каждый FastCGI процесс в своем chroot (смена корневого каталога приложения без возможности доступа за его пределы), отличном как от chroot иных процессов, так и от chroot веб-сервера. И, как мы уже говорили, позволяют работать с FastCGI приложениями расположенными на других серверах через TCP/IP, в случае локального доступа следует выбирать доступ через UNIX-сокет, как быстрый тип соединения.

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

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

SCGI, PCGI, PSGI, WSGI и прочие

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

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

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

SCGI (Simple Common Gateway Interface ) - простой общий интерфейс шлюза - разработан как альтернатива CGI и во многом аналогичен FastCGI, но более прост в реализации. Все, о чем мы рассказывали применительно к FastGCI справедливо и для SCGI.

PCGI (Perl Common Gateway Interface ) - библиотека Perl для работы с интерфейсом CGI, долгое время являлась основным вариантом работы с Perl-приложениями через CGI, отличается хорошей производительностью (насколько это применимо к CGI) при скромных потребностях в ресурсах и неплохой защиты от перегрузки.

PSGI (Perl Web Server Gateway Interface ) - технология взаимодействия веб-сервера и сервера приложений для Perl. Если PCGI представляет собой инструмент для работы с классическим CGI интерфейсом, то PSGI более напоминает FastCGI. PSGI-сервер представляет среду для выполнения Perl-приложений которая постоянно запущена в качестве службы и может взаимодействовать с веб-сервером через TCP/IP или UNIХ-сокеты и предоставляет Perl-приложениям те же преимущества, что и FastCGI.

WSGI (Web Server Gateway Interface ) - еще один специфичный интерфейс шлюза, предназначенный для взаимодействия веб-сервера с сервером приложений для программ, написанных на языке Phyton.

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

Сервер приложений как модуль Apache

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

Можно сказать, что это своего рода веб-сервер "по умолчанию". Возьмите любой массовый хостинг - там окажется Apache, возьмите любое веб-приложение - настройки по умолчанию выполнены под Apache.

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

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

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

Собственно, что такого сделали разработчики Apache, что позволило их детищу занять особое место? Ответ достаточно прост: они пошли своим путем. В то время как CGI предлагал абстрагироваться от конкретных решений, сосредоточившись на универсальном шлюзе, в Apache поступили по-другому - максимально интегрировали веб-сервер и сервер приложений.

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

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

Второе преимущество - производительность. Снова огорчим поклонников Nginx, благодаря работе в едином адресном пространстве, по производительности сервера приложений Apache + mod_php всегда будет на 10-20% быстрее любого иного веб-сервера + FastCGI (или иное CGI решение). Но также следует помнить, что скорость работы сайта обусловлена не только производительностью сервера приложений, но и рядом иных условий, в которых альтернативные веб-сервера могут показывать значительно лучший результат.

Но есть еще одно, достаточно серьезное преимущество, это возможность настройки сервера приложений на уровне отдельного сайта или пользователя. Давайте вернемся немного назад: в FastCGI/CGI схемах сервер приложений - это отдельная служба, со своими, отдельными, настройками, которая даже может работать от имени другого пользователя или на другом хосте. С точки зрения администратора одиночного сервера или какого-нибудь крупного проекта - это отлично, но для пользователей и администраторов хостинга - не очень.

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

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

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

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

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

Второй минус - более высокое потребление ресурсов. В схеме с CGI сервер приложений генерирует страницу и отдает ее веб-серверу, освобождая ресурсы, связка Apache + mod_php держит ресурсы сервера приложений занятыми до тех пор, пока веб-сервер не отдаст содержимое страницы клиенту. Если клиент медленный, то ресурсы будут заняты на все время его обслуживания. Именно поэтому перед Apache часто ставят Nginx, который играет роль быстрого клиента, это позволяет Apache быстро отдать страницу и освободить ресурсы, переложив взаимодействие с клиентом на более экономичный Nginx.

Заключение

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

Контроль ошибок при написании кода

Мониторинг сайта в поисковых системах

Создание эскиза будущего проекта

Онлайн-сервисы для решения задач дизайна и веб-разработки

• Работа с сервером

Установка сервера Apache

Установить и настроить локальный сервер на своем компьютере, благодаря Denver и ему подобным программам стало довольно просто. Об этом написано много, да и сам процесс установки интуитивно понятен. Но можно настроить сервер и без помощи вспомогательного софта, установив только то, что требуется в работе. В этой статье поговорим о том, как установить сервер Apache на свой компьютер и настроить его для дальнейшей работы.

Установка и настройка PHP

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

Установка и настройка сервера баз данных (MySQL)

Если Вы собираетесь делать сайты с использованием баз данных (а так скорее всего и будет), то для полноценной работы помимо Apache и PHP понадобится установить и настроить сервер баз данных - в нашем случае это MySQL. Об этом и будет идти речь в данной статье.

Установка и настройка phpMyAdmin

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

Мы выпустили новую книгу «Контент-маркетинг в социальных сетях: Как засесть в голову подписчиков и влюбить их в свой бренд».

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

Больше видео на нашем канале - изучайте интернет-маркетинг с SEMANTICA

Любой компьютер можно сделать сервером. Для этого нужно установить специальную оболочку.

Требования к технической части определяются количеством размещенных ресурсов и требованиями к скорости. Чем они больше, тем мощнее должен быть компьютер.
Чтобы было понятно, приведем аналогию. Вы заходите в библиотеку и просите выдать вам книгу. Библиотекарь находит нужную и передает вам. Библиотека - это сервер, в ней хранятся все данные. Библиотекарь - это оболочка, которая приняла запрос и направила ответ. Вы - клиент.
Можно отправить библиотекаря за дополнительной информацией – аналогично щелчку по ссылке. Разница в том, что один и тот же ресурс в интернете могут одновременно читать неограниченное число пользователей.
Обслуживание клиента производится по схожему принципу: приходя за книгой, мы можем задать вопрос библиотекарю (поисковая система) или заглянуть в указатель (ЯндексКаталог). Это помогает найти нужную информацию.

Что делает веб-сервер

Его главная задача – хранение информации. Страницы, файлы, изображения, текстовый контент.
Задачи:

• Получать запросы.
• Запускать программы на специальных языках программирования (серверных).
• Формировать веб страницы.
• Отправлять их назад пользователю.
• Защищать информацию.
• Проводить идентификацию посетителей.
• Вести журнал обращений.
• Обслуживать запросы других типов: mailto, и т.д.

Чтобы понять, как работает веб-сервер, надо иметь представление о принципах передачи информации в сети. В основе лежат правила, называемые протоколами: любой URL начинается с указания типа (ftp, http://, https:// и пр.).
Hyper Text Transfer Protocol – протокол передачи . Страницы сайта всегда имеют вид гипертекстового документа. Это конечный результат работы любой серверной или клиентской программы.

• Когда пользователь вводит адрес или нажимает ссылку, браузер передает запрос, кодируя информацию по этим правилам.
• Хост, к которому привязан этот адрес, запускает программы сервера. Каждая из них выполняет свои функции.
• Полученные данные расшифровываются, команды выполняются.
• Формируется гипертекст, кодируется и отправляется обратно.
• Браузер получает ответ, преобразовывает код в html и показывает на экране страницу.

Что нужно для веб-сервера

Нужна машина, которая будет обрабатывать все запросы. Оцените нагрузку, которую должен выдерживать сервер. Это зависит от количества посетителей: чем больше запросов, тем требуется большая мощность.

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

Когда решен вопрос с сервером, надо привязать к нему статический IP-адрес.

Сайт становится доступен на веб-сервере после того, как зарегистрировано доменное имя, выполнено преобразование адресов службой DNS - связывание IP-адреса (например, 111.111.111.111) и доменного имени (www.site.com).

Самые распространенные сервера

Apache

Это бесплатный, свободно распространяемый продукт, у которого есть масса преимуществ:

• Постоянная поддержка разработчиков.
• Модули для работы с серверными языками программирования PHP, Perl, Python, Ruby, ASP и т.д.
• Открытый код. Доработкой под свои нужды занимаются разные программисты. Например, русскоязычное сообщество адаптирует его к русской кодировке.
• . Изначально был создан под Unix, но сейчас поддерживается Windows, Mac OS, BSD, Linux, OS/2 и Novell NetWare.
• Безопасность.

При инсталляции укажите имя вашего хоста, например, localhost. В папку htdocs, которая лежит внутри папки Apachex.x (где x.x – номер версии) скопируйте любую html-страницу. Или создайте ее в блокноте, введя любой текст и сохранив с расширением html.

Когда в папке появился файл, откройте браузер и наберите адрес: localhost://ИМЯ СТРАНИЦЫ.html. На экране появится ваш текст – страница открыта с сервера. Если вы увидели ошибку «Не удается получить доступ к сайту», значит не запущен Apache. Его значок находится в трее.
Нажмите на него и выберите «Play». После этого все заработает.

NGNIX

Доля работающих на нем активных площадок составляет 21,13% (исследования Netcraft). Его в основном используют крупные компании и профессиональные разработчики: Yandex, Mail.ru, Rambler и пр. NGNIX выдерживает огромную нагрузку посетителей, надежен, безопасен и продуман.
Распространяется свободно, но появились платные версии Plus, стоимость от 2,500 $.

IIS

Его известность обеспечена громким именем разработчика. Представляет собой набор веб служб и интегрирован с Windows. Родной платформой программирования является ASP.NET, но можно внедрить и альтернативу, например, РНР.

Для полноценного хостинга требуется установка серверной операционной системы от Microsoft – Windows Server. 6-я версия вообще не была предназначена для хостинга, полноценная поддержка началась в 7-й. Приобретается он автоматически вместе с операционной системой и зависит от ее характеристик.

Установочные пакеты

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

• OpenServer. Портативная среда разработки, включающая множество баз данных, языков программирования и их версий, а также дополнительные сервисы. Например, интерфейс работы с БД PhpMyAdmin. На сегодняшний день это самый популярный инсталляционный набор. Работает даже с флешки. Бесплатно скачивается на низкой скорости. За 100 рублей скорость увеличивается в разы.
• Xampp. Активно поддерживаемый пакет: Apache, Php, Perl, MariaDB и пр. Имеет панель управления. Скачивается бесплатно.
• . Очень удобный набор всех нужных инструментов, включающий Apache, PHP, MySQL, PhpMyAdmin. К сожалению, последняя версия включает устаревшие дистрибутивы. В целом для обучения подойдут и они. Судя по форуму проект больше не поддерживается.

Любое оборудование, в том числе и серверное, иногда начинает работать непредсказуемо. Абсолютно не важно - новое ли это оборудование, или же оно уже несколько лет работает с полной нагрузкой.

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

Ниже мы расскажем о некоторых интересных и нетривиальных случаях.

Обнаружение неполадок

Регистрация проблемы чаще всего происходит после обращения клиентов в службу технической поддержки посредством тикет-системы.

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

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

Если становится ясно, что проблема аппаратная (например, сервер не видит часть оперативной памяти), то на этот случай у нас всегда есть в резерве аналогичная серверная платформа.

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

Примеры неполадок и способы их устранения

Сбой в работе сети на сервере

Существует вероятность, что после переноса дисков со сбойного сервера на резервный перестанет работать сеть на сервере. Это обычно происходит в случае использования операционных систем семейства Linux, например Debian или Ubuntu.

Дело в том, что при первоначальной установке операционной системы, MAC-адреса сетевых карт записываются в специальный файл, расположенный по адресу: /etc/udev/rules.d/70-persistent-net.rules.

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

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

Операционная система, не найдя этого файла, автоматически сгенерирует аналогичный и сопоставит интерфейсы уже с новыми MAC-адресами сетевых карт.

Перенастройки IP-адресов после этого не требуется, сеть сразу начнет работать.

Плавающая проблема с зависаниями

Однажды к нам на диагностику поступил сервер с проблемой случайных зависаний в процессе работы. Проверили логи BIOS и IPMI - пусто, никаких ошибок. Поставили на стресс-тестирование, нагрузив все ядра процессора на 100%, с одновременным контролем температуры - завис намертво через 30 минут работы.

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

Далее следовало исключить вероятные сбои модулей оперативной памяти, поэтому поставили сервер на тест памяти с помощью достаточно популярного Memtest86+. Минут через 20 сервер ожидаемо завис, выдав ошибки по одному из модулей оперативной памяти.

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

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

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

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

Мнимое зависание сервера при установке ОС

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

К нам обратился пользователь с жалобой на зависание сервера при попытке установки операционной системы Windows Server 2008 R2. После успешного запуска инсталлятора, сервер прекращал реагировать на мышь и клавиатуру в KVM-консоли. Для локализации проблемы подключили к серверу физическую мышь и клавиатуру - все то же самое, инсталлятор запускается и перестает реагировать на устройства ввода.

На тот момент этот сервер у нас был одним из первых на базе материнской платы X11SSL-f производства Supermicro. В настройках BIOS был один интересный пункт Windows 7 install, выставленный в Disable. Поскольку Windows 7, 2008 и 2008 R2 разворачиваются на одном и том же инсталляторе, выставили этот параметр в Enable и чудесным образом мышь и клавиатура наконец-то заработали. Но это было лишь только начало эпопеи с установкой операционной системы.

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

Википедия сообщила, что проблема решается отключением в BIOS поддержки USB 3.0 (XHCI-контроллера). Когда мы открыли документацию к материнской плате, нас ожидал сюрприз - разработчики решили полностью отказаться от контроллера EHCI (Enhanced Host Controller Interface) в пользу XHCI (eXtensible Host Controller Interface). Иными словами, все порты USB на этой материнской плате являются портами USB 3.0. И если отключить контроллер XHCI, то мы этим самым отключим и устройства ввода, сделав невозможным работу с сервером и соответственно установку операционной системы.

Поскольку серверные платформы не были оборудованы приводами для чтения CD/DVD дисков, единственным решением проблемы стало интегрирование драйверов непосредственно в дистрибутив операционной системы. Только интегрировав драйвера контроллера USB 3.0 и пересобрав установочный образ, мы смогли установить Windows Server 2008 R2 на этот сервер, а этот случай вошел в нашу базу знаний, чтобы инженеры не тратили лишнее время на бесплодные попытки.

Еще забавнее бывают случаи, когда клиенты привозят нам оборудование на размещение, а оно ведет себя не так, как ожидается. Именно так и произошло с дисковой полкой линейки Dell PowerVault.

Устройство представляет собой систему хранения данных c двумя дисковыми контроллерами и сетевыми интерфейсами для работы по протоколу iSCSI. Помимо этих интерфейсов присутствует MGMT-порт для удаленного управления.

Среди наших услуг для размещенного оборудования как раз есть специальная услуга «Дополнительный порт 10 Мбит/с», которую заказывают в случае необходимости подключения средств удаленного управления сервером. Эти средства носят разные названия:

• «iLO» у Hewlett-Packard;
• «iDrac» у Dell;
• IPMI у Supermicro.

Функционал у них приблизительно одинаков - мониторинг состояния сервера и доступ к удаленной консоли. Соответственно большая скорость канала им не требуется - 10 Мбит/с вполне достаточно для комфортной работы. Именно эта услуга и была заказана клиентом. Мы проложили соответствующую медную кроссировку, и настроили порт нашего сетевого оборудования.

Для ограничения скорости порт просто настраивается как 10BASE-T и включается в работу, имея максимальную скорость в 10 Мбит/с. После того, как все было готово - мы подключили MGMT-порт дисковой полки, но клиент почти сразу сообщил, что у него ничего не работает.

Проверив состояние порта коммутатора, мы обнаружили неприятную надпись «Physical link is down». Такая надпись говорит, что имеется проблем с физическим соединением между коммутатором и подключенным в него клиентским оборудованием.

Плохо обжатый коннектор, сломанный разъем, перебитые жилы в кабеле - вот небольшой перечень проблем, которые приводят именно к отсутствию линка. Разумеется, наши инженеры сразу взяли тестер витой пары и проверили соединение. Все жилы идеально прозванивались, оба конца кабеля были обжаты идеально. К тому же, включив в этот кабель тестовый ноутбук, мы получили как и положено соединение со скоростью 10 Мбит/с. Стало ясно, что проблема на стороне оборудования клиента.

Поскольку мы всегда стараемся помочь нашим клиентам в решении проблем, решили разобраться, что именно вызывает отсутствие линка. Внимательно изучили разъем порта MGMT - все в порядке.

Нашли на сайте производителя оригинальную инструкцию по эксплуатации, чтобы уточнить - возможно ли со стороны программного обеспечения «погасить» данный порт. Однако такой возможности не предусматривалось - порт в любом случае поднимался автоматически. Несмотря на то, что подобное оборудование должно всегда поддерживать Auto-MDI(X) - иными словами правильно определять какой кабель включен: обычный или кроссовер, мы эксперимента ради обжали кроссовер и включили в тот же порт коммутатора. Пробовали принудительно выставлять параметр дуплекса на порту коммутатора. Эффект был нулевой - линка не было и идеи уже заканчивались.

Тут кто-то из инженеров высказал абсолютно противоречащее здравому смыслу предположение, что оборудование не поддерживает 10BASE-T и будет работать только на 100BASE-TX или даже на 1000BASE-X. Обычно любой порт, даже на самом дешевом устройстве совместим с 10BASE-T и вначале предположение инженера отмели как “фантастику”, но от безысходности решили попробовать переключить порт в 100BASE-TX.

Нашему удивлению не было предела, линк мгновенно поднялся. Чем именно обусловлено отсутствие поддержки 10BASE-T на порту MGMT остается загадкой. Такой случай - очень большая редкость, но имеет место быть.

Клиент был удивлен не меньше нашего и очень благодарил за решение проблемы. Соответственно ему так и оставили порт в 100BASE-TX, ограничив скорость на порту непосредственно с помощью встроенного механизма ограничения скорости.

Отказ турбин охлаждения

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

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

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

Оригинал такой детали стоит около $100 и ее нельзя просто так пойти и купить - надо заказывать из-за рубежа. Благо в интернете обнаружили схему с оригинальной распиновкой и выяснили, что один из пинов как раз отвечает за считывание количества оборотов двигателя в секунду.

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

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

А где же диски?

В некоторых случаях причина проблемы порой настолько нетривиальна, что на ее поиск уходит очень большое количество времени. Так и получилось, когда один из наших клиентов пожаловался на случайный отвал дисков и зависание сервера. Аппаратная платформа - Supermicro в корпусе 847 (форм-фактора 4U) с корзинами для подключения 36-ти дисков. В сервере было установлено три одинаковых RAID-контроллера Adaptec, к каждому подключено по 12 дисков. В момент возникновения проблемы, сервер переставал видеть случайное количество дисков и зависал. Сервер вывели из продакшн и приступили к диагностике.

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

Через две недели снова обращение с той же проблемой. Было решено заменить контроллер на аналогичный. Выполнили, прошили, подключили, поставили на тесты. Проблема осталась - через пару дней выпали все диски уже на новом контроллере и сервер благополучно завис.

Переустановили контроллер в другой слот, заменили бэкплейн и SATA-кабели от контроллера до бэкплейна. Неделя тестов и снова диски выпали - сервер вновь завис. Обращение в поддержку Adaptec результатов не принесло - они проверили все три контроллера и проблем не обнаружили. Заменили материнскую плату, пересобрав платформу чуть ли не с нуля. Все, что вызывало малейшие сомнения заменили на новое. И проблема вновь проявилась. Мистика да и только.

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

Заключение

Конечно, это лишь малая часть интересных ситуаций, которые были решены нашими инженерами. Некоторые проблемы «отловить» достаточно непросто, особенно когда в логах нет никаких намеков на произошедший сбой. Зато любые подобные ситуации стимулируют инженеров детально разбираться в устройстве серверного оборудования и находить самые разнообразные решения проблем.

Вот такие забавные случаи были в нашей практике.
А с какими сталкивались вы? Добро пожаловать в комментарии.