Переход с сервера Apache 1.3 на Apache 2.0

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

Все ситуации, рассмотренные в этой статье, произошли при переносе сайта apache.org на сервер Apache 2.0. Это случилось довольно давно, задолго до выпуска первой бета версии, поэтому некоторые детали могут не совпадать, но в основном все действия остаются актуальными. Также хочу выразить благодарность: не я перенес сайт Apache.org на сервер Apache 2.0. Я начал работать над этим, но потом, по личным причинам, передал эту работу для завершения Грэгу Амесу (Greg Ames). Я наблюдал за тем, что он делает, и помогал ему с возникающими проблемами, но Грэк - это тот человек, который получил сайт apache.org, превосходно работающий на сервере Apache 2.0.

Когда мы планировали переход на другой сервер, то нашим главным приоритетом была непрерывная работа сервисов сайта apache.org. Сайт apache.org не самый загруженный сайт в сети, но в середине дня сайт испытывает приличную нагрузку, и когда сайт не справляется с ней, наши посетители начинаются испытывать трудности с доступом. Чтобы избежать этого, мы запланировали произвести установку сервера Apache 2.0 на порт 8091 и известить об этом посетителей. Тем самым проверить, как он будет работать. После недельной проверки сервера на работоспособность, мы переключили его на порт 80.

Поддержка многопроцессности.

Перед тем как начать устанавливать сервер, мы приняли некоторые решения. Ведь сервер Apache 2.0 гораздо более гибкий в настройке, чем Apache 1.3. Первое решение, которое необходимо было сделать - это какой многопроцессный модуль (MPM) использовать (для детального описания всех MP-модулей, смотрите первую статью).

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

MP-модули начинают работать только после создания процессов и нитей.Лучший пример этого - модуль mod_cgid. Большинство версий Unix плохо распараллеливают процессы на нити. Вместо создания нового однонитевого процесса, они копируют исходный процесс со всеми нитями, а затем завершать все нити, кроме одной. Очевидно, что это не самый эффективный путь создания процессов. Решения, которые приняли разработчики Apache, это создать CGI-демона, которого использовал бы Apache для создания новых CGI-процессов. Этот демон-процесс создается до создания любых дочерних процессов, и он состоит только из одной нити. Когда CGI-запрос получен, он отсылается CGI-демону, и это демон создает параллельный CGI-процесс. После завершения обработки, CGI-процесс отсылает результирующие данные обратно дочернему процессу, для отсылки результата клиенту.

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

Установка фильтров.

Последнее главное отличие мужду Apache 1.3 и Apache 2.0 - это добавление фильтров. Для программистов, фильтры являются мощным средством изменения данных, созданных другим модулем. Для администраторов, фильтры требуются для фильтрации трафика. Только один стандартный модуль реализует функции фильтра - это модуль mod_include, поэтому мы сфокусируемся на нем. В apache 1.3, когда вы хотели, чтобы все файлы .shtml были проанализированы на SSI ДИРЕКТИВЫ, вам необходимо было использовать строку, подобную этой:

AddHandler server-parsed .shtml 

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

SetOutputFilter INCLUDES 

Эта директива может быть определена в контейнерах File, Directory или Location, для уверенности, что любые данные, отправленные клиенту, проанализированы на SSI директивы. Однако ваш конфигурационный файл может стать более объемным и сложным для чтения. Также это означает, что обработчики и mime-типы перестали быть настолько важными для Apache как раньше. Большинство модулей, которые генерируют данные, могут использовать стандартный обработчик для чтения файла с диска и использовать фильтр для изменения прочитанных данных.

Трудности с IPv6

К сожалению, установка нашего сервера принесла больше трудностей, чем мы ожидали. Первая проблема была с настройкой виртуальных хостов; все сайты Apache.org находятся на одной машине, поэтому логично, что мы считали это важной возможностью сервера. Наша проблема заключалась в том, что сайт apache.org работал на платформе, которая понимала и IPv4, и IPv6. Сервер Apache 2.0 поддерживает IPv6 автоматически, но проблема в том, что на платформах, которые тоже поддерживают IPv6, серверная поддержка работает слишком хорошо.

Если ваша платформа поддерживает IPv6, то очень сложно заставить Apache 2.0 использовать IPv4. Разработчики сервера обсуждали возможность использования конфигурационного флага, для определения типа адресации. Тем не менее, до сих пор эта директива не реализована. Сейчас, если у вас возникли проблемы с доступом к серверу, то проблема, вероятно, будет в поддержке IPv6. Чтобы решить эту проблему, вы можете использовать спецификатор * в вашем конфигурационном файле для определения IP адресов. Это заставит ваш сервер связать некоторый порт со всеми адресами.

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

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

Заключение

Вышеизложенные вещи были единственными, которые нам затруднили переход с Apache 1.3 на Apache 2.0. Данная статья не покрывает всех проблем, которые могут у вас случиться при переходе на Apache 2.0, но я надеюсь, что я предоставил ответ на большинство возникающих вопросов и дал вам стартовую точку для вашего перехода. Также я хочу вам напомнить, что Apache только тогда станет лучше, когда его пользователи будут помогать разработчикам. Поэтому, если вы обнаружили проблему, которую вы не можете решить, пожалуйста, оставить отчет о ней в базе ошибок на http://bugs.apache.org.

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