Администрирование сервера Apache и руководство по электронной коммерции

Администрирование Web-сервера Apache и руководство по электронной коммерции - Хоккинс С. - 2001

Эта книга задумывалась как достаточно полное справочное руководство по Web-серверу Apache . Изложенный в ней материал предполагает определенный уровень компьютерной грамотности, но знания сетевых технологий при этом не требуется. Несмотря на то, что основная проблематика книги лежит в области электронной коммерции, в приложениях затронуты самые разнообразные проблемы и информация, необходимая для создания и функционирования Web-сервера. Это проблема соответствия имен и IP-адресов, детали протокола TCP/IP и синтаксис регулярных выражений. Кроме того, в перспективе Web-администрирования затронуты темы создания системы электронных платежей и взаимодействия с базами данных.

Хокинс, Скотт.
Администрирование Web-сервера Apache и руководство по электронной коммерции.
Пер. с англ. М. : Издательский дом "Вильяме", 2001. - 336 с. : ил, - Парал. тит.англ.
ISBN 5-8459-0212-6 (рус.)
ISBN 0-13-089873-2 (англ.)
ББК 32.973.26-018.2.75
УДК 681.3.07
Х68

ЧАСТЬ I. ОСНОВЫ
Глава 1. ОСНОВНЫЕ КОНЦЕПЦИИ
Глава 2. ИНСТАЛЛЯЦИЯ WEB-СЕРВЕРА APACHE
Глава 3. КОНФИГУРИРОВАНИЕ WEB-СЕРВЕРА APACHE
Глава 4. ЗАПУСК, ПЕРЕЗАПУСК И ОСТАНОВКА СЕРВЕРА

ЧАСТЬ II. АДМИНИСТРИРОВАНИЕ WEB-CEPBEPA
Глава 5. ХОСТИНГ НЕСКОЛЬКИХ WEB-УЗЛОВ
Глава 5. PROXT-СЕРВЕРЫ И КЭШИРОВАНИЕ
Глава 7. РЕГИСТРАЦИЯ И МОНИТОРИНГ
Глава 8. БЕЗОПАСНОСТЬ
Глава 9. ДИНАМИЧЕСКИЕ WEB-СТРАНИЦЫ
Глава 10. НАСТРОЙКА РАБОЧИХ ХАРАКТЕРИСТИК СЕРВЕРА
Глава 11. ПЕРЕНАЗНАЧЕНИЕ АДРЕСА
Глава 12. СОСТАВ МОДУЛЯ

ЧАСТЬ III. ЭЛЕКТРОННАЯ КОММЕРЦИЯ
Глава 13. ДЕНЕЖНЫЕ ПЛАТЕЖИ
Глава 14. ВЗАИМОДЕЙСТВИЕ С БАЗАМИ ДАННЫХ
Глава 15. ПРИМЕР КОММЕРЧЕСКОГО УЗЛА

ЧАСТЬ IV. ПРИЛОЖЕНИЯ
Приложение А. ОСНОВНЫЕ ДИРЕКТИВЫ
Приложение Б. ПРОЧИЕ ДИРЕКТИВЫ
Приложение В. КОНЦЕПЦИЯ ПРОТОКОЛА TCP/IP
Приложение Г. ПРЕОБРАЗОВАНИЕ ИМЕН В IP-АДРЕСА
Приложение Д. РЕШЕНИЕ ПРОБЛЕМ, ВОЗНИКАЮЩИХ ПРИ РАБОТЕСЕТИ
Приложение Е. КОНЦЕПЦИЯ UNIX
Приложение Ж. КОНЦЕПЦИЯ WINDOWS NT
Приложение 3. КОДЫ СОСТОЯНИЯ HTTP
Приложение И. РЕГУЛЯРНЫЕ ВЫРАЖЕНИЯ
Приложение К. ИНТЕРФЕЙС MOD_PERLAPI
Приложение Л. ОПЕРАТОРЫ ЯЗЫКА РНР

Предметный указатель

Бесплатно скачать электронную книгу в удобном формате, смотреть и читать:
Скачать книгу Администрирование Web-сервера Apache и руководство по электронной коммерции - Хоккинс С. - 2001 - fileskachat.com, быстрое и бесплатное скачивание.

Скачать pdf
Ниже можно купить эту книгу по лучшей цене со скидкой с доставкой по всей России. Купить эту книгу

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

Сервер Apache имеет возможность конфигурирования для поддержки множества IP адресов (см. директивы BindA ddress и Listen). Для каждого IP адреса он может поддерживать множество портов1 . Каждая комбинация сопровождаемых IP адресов и портов имеет один или много узлов. В этой главе детализируется три метода настрой ки сервера Apache для обеспечения хостинга нескольких узлов:

1. Домашние страницы пользователей.

2. Виртуальный хостинг по имени.

3. Виртуальный хостинг по IP адресу.

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

1 Термины IP адрес и порт детально обсуждаются в приложении А, "Основные директивы".

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

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

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

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

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

5.2. Домашние страницы пользователей

При применении этого метода испол ьзуется директива UserDir для того, чтобы разместить URL в некоторых каталогах системы, как это показано на рис. 5.1.

5.2.1. Директива UserDir some_directory

Эта директива предназначена для того, чтобы показать, что Web содержимое будет найдено в конкретном подкаталоге корневого каталога пользователя. Когда работает эта директива, сервер Apache принимает запросы в виде:

http://www.example.com/~userguy

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

UserDir some_directory,

сервер Apache будет искать отображаемое Web содержимое в подкаталоге some_directory каталога /home/userguy 3 . В соответствии с логикой нашего приме ра это приведет в каталог

/home/userguy/some_directorу

2 Броузеры, реализующие стандарты HTTP меньше, чем 1.1, из за причин, о которых мы расскажем позднее, не могут поддерживать хостинг по имени.

3 Значение по умолчанию public_html

Рис. 5.1. Домашние страницы пользователей

5.2.2. Директива UserDir /an/absolute/path

Есть способ, заключающийся в задании абсолютного пути к определенному ката логу, в котором хранится Web содержимое всех пользователей. Этот метод предпола гает, что каждый пользователь имеет свой собственный подкаталог в каталоге, задан ном директивой UserDir.Например, если сервер Apache получает URL

http://www.example.com/~timmy/x flies.html,

когда действует директива UserDir /var/user/webspace,

то сервер возвращает /var/user/webspace/timmy/x files.html

5.2.3. Директива UserDir /an/absolute/*/with/wildcard

Из всех трех вариантов директивы UserDir этот вариант самый вероятный претендент на применение. В этом методе задается абсолютный путь к каталогу, где пользователи хра нят свои Web документы. Здесь вместо имени пользователя указывается звездочка "*". И когда сервер Apache получает запрос к определенному пользователю

http://www.example.com/~susie,

он анализирует имя пользователя (об этом свидетельствует символ "~") и замещает звездочку именем пользователя. Например, если в настоящий момент действует ди ректива UserDir:

UserDir /home/*/public_html,

сервер Apache переадресует этот URL в каталог /home/susie/public_html

5.3. IP$адреса и порты

Перед тем как сконфигурировать виртуальный хостинг, необходимо настроить сервер на прослушивание соответствующих портов. По умолчанию сервер Apache следит за IP

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

5.3.1. Определение IP$адресов:

директива BindAddress address

Директива BindAddress задает серверу Apache режим мониторинга определенного IP адреса или целого ряда адресов. Следующая директива устанавливает режим про слушивания сервером Apache адреса 192.168.1.10:

BindAddress 192.168.1.10

Чтобы прослушивались все активные IP адреса, нужно задать команду

5.3.2. Определение одного IP$порта: директива Port portnum

По умолчанию сервер Apache прослушивает IP порт 80 заданного IP адреса. Это правильно, так как порт 80 является "стандартным портом", определенным протоко лом HTTP, и поэтому к нему будет обращаться наибольшее число Web броузеров.

С другой стороны, может потребоваться изменить эту стандартную установку и, таким образом, ограничить доступ только теми броузерами, которые знают прослуши ваемый порт. Типичнымпримером такого использования сервера Apache является ис пользование его в качестве proxy-сервера, а еще такой режим работы может приго диться для настройки корпоративной intranet. Отметим, что в отличие от директивы Listen (которая будет рассмотрена в следующем разделе), только одна директива Port может быть применена в один момент времени. Например, чтобы сервер Apache начал прослушивать порт 4444, необходимо задать директиву

5.3.3. Определение одного или более IP$порта: директива Listen

В отличие от директивы Port, директива Listen не отменяет действие других ди ректив Listen. Чтобы сервер Apache слушал порт 80 (стандарт HTML) и порт (гипотетический локальный порт), воспользуемся последовательностью директив

Кроме того, директива Listen может использоваться для определения IP адресов. Предположим, что в вышеприведенном примере прослушивается IP адрес 192.168.1.2. Следующие команды Listen будут иметь аналогичный эффект:

Listen 192.168.1.2:80

Listen 192.168.1.2:

5.3.4. Настройка множества IP$портов

Можно предложить два метода поддержки множества IP адресов на одной системе:

Купить и установить несколько интерфейсных плат.

В некоторых операционных системах для установки мониторинга одной интерфейс ной платы множеством IP адресов можно воспользоваться командой ifconf ig.

Совершенно очевидно, что идея покупки множества интерфейсных карт не нуждается в комментариях. Чего нельзя сказать об использовании команды ifconfig . Команда ifconfig (interface configurationконфигурация- интерфейса) выполняет две функции:

Отображение информации о конфигурации существующего интерфейса.

Изменение или добавление информации о конфигурации интерфейса.

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

/home/root> ifconfig eth0

В результате будет получен следующий ответ (конечно, в зависимости от типа системы):

eth0 Link encap:Ethernet HWaddr 0 0: 2 0: 7 8: 1 7: 9 A: Е В

inet addr:192.168.1.1 Beast:192.168.1.255 mask:255 . 255 . 255 . 0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:!

RX packets:260652 errors:0 dropped:0 overruns:0 frame:0

TX packets:565370 errors:0 dropped:0 overruns:0 carrier:0 collisions:0

С другой стороны, команду ifconfig иногда можно использовать для ввода новой информации. Вот команда, которая создает виртуальное устройство eth0:l. Оно бу дет отслеживать различные IP адреса (192.168.100.2).

/home/root> ifconfig eth0:1 192.168.1.2 netmask 255 . 255 . 255 . 0

В случае успешного конфигурирования, устройство et h0:1 ведет себя так, будто оно присутствует в действительности, отвечая на запросы команды pings и запросы пользователей, как если бы вы и правда потратили 50 долларов на новую карту.

5.4. Виртуальный хостинг по имени

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

Это, без всяких сомнений, хорошее решение несколько снизило скорость истоще ния адресного пространства Internet. Проблема заключается только в том, что с заго ловком HOST работают только броузеры, удовлетворяющие стандарту HTTP 1.1. По этому получить доступ к таким виртуальным узлам в помощью устаревших броузеров будет довольно проблематично.

Процесс настройки такого хостинга можно разбить на три этапа:

Информирование DNS о том, что уже существующий IP адрес также имеет от ношение к имени нового виртуального узла.

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

5.4.1. Система доменных имен и регистрация имени

Система доменных имен (DNS) - это своеобразный аналог желтых страниц Inter net. Это распределенная база данных IP адресов и связанных с ними доменных имен. Без системы доменных имен или чего нибудь подобного Internet не смог бы сущест вовать. Без базы DNS, задаваемый в броузере URL является совершенно бесполезным до тех пор, пока соответствующий ему IP адрес не будет найден в базе данных DNS.

Учитывая продолжающееся расширение Internet, хороших доменных имен остается все меньше и меньше. Уже все возможные трехбуквенные комбинации имен доменов исчерпаны, так что по этому поводу даже не стоит беспокоиться. Большинство анг лийских слов уже тоже использованы. Запрос по получению новых доменных имен можно направлять по адресу http://www.networksolutions.com (см. рис. 5.2).

Рис. 5.2. Регистрация доменного имени

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

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

5.5. Настройка виртуального хостинга по имени на сервере Apache

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

1. С помощью директивы NameVirtualHost определить IP адрес, который будет использоваться для виртуального хостинга.

2. С помощью пары директив Vir tualHost выделить директивы, которые будут иметь отношение только к определенному виртуальному Web узлу.

5.5.1.НазначениеIPдля виртуальногохостингапоимени: NameVirtualHost

С помощью директивы NameVirtualHost задайте IP адрес виртуального узла в конфигурационном файле httpd.conf. Например директива вида

NameVirtualHost 192.168.1.1

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

Номер порта можно задать с помощью директивы NameVirtualHost.

NameVirtualHost 192.168.1.1:80

Виртуальный хостинг по имени работает только для Web броузеров, удовлетво ряющих стандарту HTTP 1.1 или выше. Причина этого заключается в том, что стан дарт HTTP 1.1 имеет директиву HOST, которая задает имя узла (и порта). Отсюда Web броузер берет информацию. Без этой директивы сервер не сможет определить, какой же из Web узлов можно ассоциировать с IP адресом, запрашиваемым пользователем.

5.5.2. Запуск виртуального хостинга: директива VirtualHost

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

ServerName www.examplel.org

DocumentRoot/some/other/directory

Необходимо обратить внимание на то, что директивы, находящиеся внутри скобок , относятся только к виртуальному узлу, заданному директивой ServerName. Директивы, заключенные в скобки , отменяют стандарт ные установки, действующие для данного IP адреса. Ограничений на количество ди ректив, которые могут быть заключены в операторные скобки , нет. Но есть определенные разумные пределы (см. табл. 5.1).

Таблица 5.1. Директивы, неприменимые в виртуальном хостинге

5.5.3. Виртуальный узел по умолчанию

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

Стандартные директивы...

5.5.4. IP$адрес или доменное имя?

При более внимательном рассмотрении команд, описанных в этой главе (VirtualHost, BindAddress и т.д.), можно заметить, что многие из них скорее предна значены для определения доменных имен, чем IP адресов. Например набор директив

Различные директивы...

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

5.6. Виртуальный хостинг по IP$адресу

Виртуальный хостинг по IP адресу не предполагает, что пользовательские броузеры бу дут посылать заголовок Host (этохарактерно только для броузеров, совместимых со стан дартом HTTP 1.1), и, следовательно, в зависимости от требований к узлу, не может пре тендовать на исключительность. Вот этапы процессавиртуального хостинга по IP адресу:

1. Создание и регистрация нового имени виртуального узла.

2. Настройка системы таким образом, чтобы она имела возможность отслеживать новые IP адреса (см. раздел "IP адреса и порты" в этой главе).

3. Задание в DNS связи между новым IP адресом и именем узла.

4. Сообщение серверу Apache о том, как можно обработать запросы, направлен ные к виртуальному узлу.

Большая часть этих требований уже обсуждалась. Сведения о том, как создаются и регистрируются новые имена узлов, можно найти в разделе "Виртуальный хостинг по имени" в этой главе. Процедура создания нового имени является аналогичной. Одна ко при регистрации имени нового виртуального узла с использованием DNS необхо димо создать новый IP адрес.

Конфигурирование системы с тем, чтобы она могла отслеживать новые IP адреса, обсуждается в разделе "IP адреса и порты" ранее в этой главе.

Основное различие между конфигурированием сервера Apache для виртуального хостинга по имени и виртуального хостинга по IP адресу заключается в том, что во втором случае не требуется прибегать к услугам директивы NameVirtualHost. Чтобы создать узел с именем www.example2.com по адресу 192.168.1.2, необходимо:

ServerNamewww.example2.com

5.6.1.Комбинированиевиртуальных узлов, базирующихся на именах и на IP$адресах

Нет причины, которая могла бы воспрепятствовать объединению обеих подходов на одной системе. Сначала создайте весь нужный виртуальный хостинг по адресу, а потом задайте соответствие адресов для виртуального хостинга по имени. Если дирек тива NameVirtualHost хоть один раз применялась к определенному IP адресу, то этот адрес уже будет потерян для виртуального хостинга по адресу.

5.7. Что нужно настраивать для виртуального хостинга

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

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

Как минимум, необходимо задать директиву ServerName для каждого виртуаль ного узла:

ServerName www . site2 . com

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

DocumentRoot /home/site2

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

ServerAdmin [email protected]

Можно упомянуть также файлы ErrorLog и TransferLog, так как иханализ уп рощает отладку и анализ трафика. Однако следует помнить, что Unix системы (включая и ОС Linux) обычно накладывают ограничение на число файлов, открывае мых отдельными процессами. Назначение отдельного регистрационного файла для каждого виртуального узла может быстро превысить этот предел. К сожалению, я вы нужден попросить вас обратиться к системной документации, чтобы узнать, каким образом можно повлиять на ограничения, накладываемые каждой конкретной систе мой. При наличии таких либо подозрений, проверьте файл syslog вашей системы. ОС Unix очень хорошо фиксирует нарушения такого типа.

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

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

Спонсор — команда системных администраторов
Centos-admin во главе с Игорем Олемским,
которая занимается удаленным обслуживанием веб-серверов.

Установка и обновление программного обеспечения на веб-сервере

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

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

Настройка веб-сервера и оптимизация скорости

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

Как вы понимаете, любой сайт можно условно представить в виде системы back-end + front-end. Они взаимозависимы и часто нагрузку на сервер можно снизить за счет оптимизации сайта. Например, установить систему кэширования или использовать географически распределенную систему доставки контента (CDN). Улучшение работы серверной части возможно за счет оптимизации Apache и PHP, инсталляции HTTP-сервера Nginx. А для того, чтобы оценить результаты настройки и оптимизации, необходимо проанализировать производительность. В Linux это выполняется стандартными утилитами, например top, iostat или ifstat. Оценку скорости загрузки сайта можно провести с помощью специализированных веб-сервисов — например, Google PageSpeed Insights.

Постоянный мониторинг активности веб-сервера

Мало просто настроить и оптимизировать сервер — за ним необходимо постоянно наблюдать и проще всего делать это с помощью систем мониторинга. Можно подключить коммерческую облачную систему, такую как CA APM Cloud Monitor, или использовать другой подобный инструмент.

Такой мониторинг надежнее системы, установленной на самом сервере, уже потому, что обладает огромным набором точек подключения и проверки. Система может проверять, насколько хорошо сервер работает для пользователей из США, Китая, Бразилии, Австралии и других стран. Системы мониторинга также круглосуточно проверяют и тестируют протоколы — от HTTP до FTP, позволяют использовать сетевые инструменты Ping, Traceroute, DNS Query и другие, формируют подробные отчеты со статистикой «взлетов и падений» сервера. Словом, с такой системой вы вряд ли пропустите даже малейший сбой.

Нагрузочное тестирование веб-сервера

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

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

Для начала, необходимо протестировать сервер на предмет работы в условиях высокой нагрузки — такую проверку называют нагрузочным тестированием. Главными метриками здесь служат скорость обработки запросов и вероятность отказа в обслуживании. Стандартные тестовые наборы, применяемые при нагрузочном тестировании, — это SPECweb99, WebBench, WebStone, TCP-W и другие. Вы можете задать такой системе сценарий нагрузки. Если ожидается приток новых пользователей в интернет-магазин, то можно отработать сценарий покупки и выяснить, при каком количестве обращений в минуту сервер перестает обслуживать запросы. А уже затем, на основе полученных цифр и графиков, делать выводы и дорабатывать систему.

Доработка системы, конечно, зависит от архитектуры. Но для большинства сайтов справедлива следующая конструкция: система управления контентом (CMS) на базе PHP, установленная на сервере Apache. Поэтому, оптимизация под высокие нагрузки обычно сводится к оптимизации Apache и PHP, установке eAccelerator, Nginx и Memcached, а также клиентской оптимизации.

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

Оптимизировать работу PHP можно за счет редактирования файла php.ini, расположенного на сервере. Например, в строке memory_limit можно выставить лимит памяти, которую движок может тратить на генерацию страницы. Не лишней будет и установка eAccelerator — это инструмент, который компилирует исходный текст на PHP в двоичный код и хранит его в оперативной памяти сервера для ускорения доступа. Для большинства ресурсов уже этих методов будет достаточно, чтобы подготовить сайт к большим нагрузкам.

Регулярное резервное копирование данных

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

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

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

Построение системы превентивной защиты веб-сервера

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

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

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

Масштабирование веб-сервера

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

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

Горизонтальное масштабирование — добавление в систему новых структурных элементов (например, увеличение парка серверов) и распределение нагрузки между ними.

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

Техническая поддержка пользователей

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

Вместо заключения: нанять специалистов или привлечь аутсорсеров?

Теперь, когда вы знакомы со всеми основными сложными задачами по администрированию веб-сервера, необходимо решить — делать все это собственными силами или отдать на аутсорсинг.

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

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

Спонсор этой статьи — компания Centos-admin и ее основатель Игорь Олемской.

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

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