переход с Apache 1.3 на 2.0 – возможные трудности
Все трудные ситуации, рассмотренные в этой статье, произошли при переносе сайта 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. Первую задачу, которую необходимо было выполнить - это выбрать, какой МП-модуль нам использовать.
Лично я советую начать с МП-модуля prefork. В Apache 2.0 было многое изменено, поэтому лучше начать с того модуля, принцип работы которого проще понять.
Итак, ваш новый сервер установлен и работает, и теперь вы можете начать экспериментировать с МП-модулями, чтобы определить, какой из них лучше подходит для вашего сайта.
МП-модули работают только при создании процессов и нитей. Рассмотрим пример этого процесса - модуль mod_cgid. Большинство версий Unix плохо распараллеливают процессы на нити. Вместо создания нового однонитиевого процесса, они копируют исходный процесс со всеми нитями, а затем завершают все нити, кроме одной. Очевидно, что это не самый эффективный путь создания процессов. Решение, которые приняли разработчики Apache - это создание CGI-демона, которого использовал бы Apache для создания новых CGI-процессов. Этот демон-процесс создается до момента создания любых дочерних процессов и состоит только из одной нити. Когда приходит CGI-запрос, он отсылается CGI-демону, который, в свою очередь, создает параллельный CGI-процесс. После завершения обработки, CGI-процесс отсылает данные обратно дочернему процессу, который отсылает их клиенту. Рассмотренный модуль не настолько отлажен, как стандартный модуль mod_cgi, поэтому, если вы используете нитиевый МП-модуль и если CGI-запросы приводят к ошибкам, для определения источника проблем можно использовать mod_cgi. Модуль mod_cgi тоже работает с МП-модулями, но его производительность оставляет желать лучшего.
установка фильтров
Последнее главное отличие между Apache 1.3 и Apache 2.0 - это добавление механизма фильтров. Для программистов фильтры являются мощным средством изменения данных, полученных от другого модуля. А для администраторов фильтры требуются для фильтрации трафика. Только один стандартный модуль реализует функции фильтра - это модуль mod_include, поэтому мы его и рассмотрим. В Apache 1.3, например, если вы хотите, чтобы все файлы .shtml были проанализированы на наличие SSI-директив, необходимо использовать строку, подобную этой:
AddHandler server-parsed .shtml
В Apache 2.0 нет обработчика server-parsed, поэтому данный подход не работает. Вместо этого, вам необходимо добавить фильтр INCLUDES, используя следующую строку:
SetOutputFilter INCLUDES
Эта директива определяется в секциях File, Directory или Location. Это сделано для уверенности в том, что действительно любые данные, отправленные клиенту, проанализированы на наличие SSI-директив. Однако из-за этого ваш конфигурационный файл может стать более объемным и сложным для чтения. Также это означает, что обработчики (Handler) и MIME-типы перестали быть настолько важными для Apache, как раньше. Большинство модулей, генерирующих данные, могут использовать стандартный обработчик для чтения файла с диска, а затем использовать фильтр для изменения считанных данных.
трудности с IPv6
К сожалению, установка нашего сервера принесла больше трудностей, чем мы ожидали. Первая проблема была с настройкой виртуальных хостов: так как все сайты apache.org физически находятся на одной машине, логично, что для нас виртуальные хосты - исключительно важная фича. Проблема заключалась в том, что сайт apache.org работал на платформе, которая понимала и IPv4, и IPv6. Сервер Apache 2.0 поддерживает IPv6 автоматически, но проблема заключается в том, что на платформах, которые тоже поддерживают IPv6, серверная поддержка работает “слишком” хорошо.
Если ваша платформа поддерживает IPv6, то очень сложно заставить Apache 2.0 использовать IPv4. Разработчики сервера обсуждали возможность использования конфигурационного флага для определения типа адресации. Тем не менее, до сих пор эта директива не реализована. Сейчас, если у вас возникли проблемы с доступом к серверу, то проблема, вероятно, будет в поддержке IPv6. Чтобы решить эту проблему, вы можете использовать спецификатор * в вашем конфигурационном файле для задания IP-адресов. Это заставит ваш сервер связать некоторый порт со всеми IP-адресами. Как уже было сказано, мы решили запустить сервер на порту 8091, чтобы протестировать его неделю перед тем, как начать использовать полноценно. Когда мы это сделали, то обнаружили, что сервер еще недостаточно стабилен для работы, так как Apache перестал отвечать на запросы через несколько часов работы.
Что же случилось? А дело в том, что существует слишком много мелких отличий между браузерами, которые могут вызывать ошибки. И их очень сложно обнаружить.
заключение
Вот и все проблемы, которые затруднили нам переход с Apache 1.3 на Apache 2.0. Данная статья не рассматривает всех проблем, которые могут у вас случиться при переходе на Apache 2.0, но я надеюсь, что она предоставляет ответы на большинство возникающих вопросов и дает вам стартовую точку для будущего «переезда» (а рано или позно он все же должен случиться). Также хочу напомнить, что Apache станет лучше только тогда, когда его пользователи будут помогать разработчикам. Поэтому, если вы обнаружили проблему, которую не можете решить самостоятельно, пожалуйста, оставьте отчет о ней в базе ошибок на http://bugs.apache.org.
Ryan Bloom, перевод Максима Сипягина
Когда мы планировали переход на новый сервер, нашей основной задачей было обеспечение непрерывной работы сервисов сайта apache.org. Сайт apache.org - не самый загруженный сайт в сети, но в середине дня сайт испытывает приличную нагрузку. А когда сайт не справляется с нагрузкой, наши посетители, естественно, начинают испытывать трудности с доступом к сайту, что не есть здорово. Чтобы избежать этого, мы запланировали установить сервер Apache 2.0 на порт 8091 и известили об этом посетителей. После недельной проверки сервера на работоспособность, мы переключили его на основной порт 80.
поддержка многопроцессности
Перед тем как начать установку сервера, мы приняли некоторые важные решения. Сервер Apache 2.0 гораздо более гибок в настройке, чем Apache 1.3. Первую задачу, которую необходимо было выполнить - это выбрать, какой МП-модуль нам использовать.
Лично я советую начать с МП-модуля prefork. В Apache 2.0 было многое изменено, поэтому лучше начать с того модуля, принцип работы которого проще понять.
Итак, ваш новый сервер установлен и работает, и теперь вы можете начать экспериментировать с МП-модулями, чтобы определить, какой из них лучше подходит для вашего сайта.
МП-модули работают только при создании процессов и нитей. Рассмотрим пример этого процесса - модуль mod_cgid. Большинство версий Unix плохо распараллеливают процессы на нити. Вместо создания нового однонитиевого процесса, они копируют исходный процесс со всеми нитями, а затем завершают все нити, кроме одной. Очевидно, что это не самый эффективный путь создания процессов. Решение, которые приняли разработчики Apache - это создание CGI-демона, которого использовал бы Apache для создания новых CGI-процессов. Этот демон-процесс создается до момента создания любых дочерних процессов и состоит только из одной нити. Когда приходит CGI-запрос, он отсылается CGI-демону, который, в свою очередь, создает параллельный CGI-процесс. После завершения обработки, CGI-процесс отсылает данные обратно дочернему процессу, который отсылает их клиенту. Рассмотренный модуль не настолько отлажен, как стандартный модуль mod_cgi, поэтому, если вы используете нитиевый МП-модуль и если CGI-запросы приводят к ошибкам, для определения источника проблем можно использовать mod_cgi. Модуль mod_cgi тоже работает с МП-модулями, но его производительность оставляет желать лучшего.
установка фильтров
Последнее главное отличие между Apache 1.3 и Apache 2.0 - это добавление механизма фильтров. Для программистов фильтры являются мощным средством изменения данных, полученных от другого модуля. А для администраторов фильтры требуются для фильтрации трафика. Только один стандартный модуль реализует функции фильтра - это модуль mod_include, поэтому мы его и рассмотрим. В Apache 1.3, например, если вы хотите, чтобы все файлы .shtml были проанализированы на наличие SSI-директив, необходимо использовать строку, подобную этой:
AddHandler server-parsed .shtml
В Apache 2.0 нет обработчика server-parsed, поэтому данный подход не работает. Вместо этого, вам необходимо добавить фильтр INCLUDES, используя следующую строку:
SetOutputFilter INCLUDES
Эта директива определяется в секциях File, Directory или Location. Это сделано для уверенности в том, что действительно любые данные, отправленные клиенту, проанализированы на наличие SSI-директив. Однако из-за этого ваш конфигурационный файл может стать более объемным и сложным для чтения. Также это означает, что обработчики (Handler) и MIME-типы перестали быть настолько важными для Apache, как раньше. Большинство модулей, генерирующих данные, могут использовать стандартный обработчик для чтения файла с диска, а затем использовать фильтр для изменения считанных данных.
трудности с IPv6
К сожалению, установка нашего сервера принесла больше трудностей, чем мы ожидали. Первая проблема была с настройкой виртуальных хостов: так как все сайты apache.org физически находятся на одной машине, логично, что для нас виртуальные хосты - исключительно важная фича. Проблема заключалась в том, что сайт apache.org работал на платформе, которая понимала и IPv4, и IPv6. Сервер Apache 2.0 поддерживает IPv6 автоматически, но проблема заключается в том, что на платформах, которые тоже поддерживают IPv6, серверная поддержка работает “слишком” хорошо.
Если ваша платформа поддерживает IPv6, то очень сложно заставить Apache 2.0 использовать IPv4. Разработчики сервера обсуждали возможность использования конфигурационного флага для определения типа адресации. Тем не менее, до сих пор эта директива не реализована. Сейчас, если у вас возникли проблемы с доступом к серверу, то проблема, вероятно, будет в поддержке IPv6. Чтобы решить эту проблему, вы можете использовать спецификатор * в вашем конфигурационном файле для задания IP-адресов. Это заставит ваш сервер связать некоторый порт со всеми IP-адресами. Как уже было сказано, мы решили запустить сервер на порту 8091, чтобы протестировать его неделю перед тем, как начать использовать полноценно. Когда мы это сделали, то обнаружили, что сервер еще недостаточно стабилен для работы, так как Apache перестал отвечать на запросы через несколько часов работы.
Что же случилось? А дело в том, что существует слишком много мелких отличий между браузерами, которые могут вызывать ошибки. И их очень сложно обнаружить.
заключение
Вот и все проблемы, которые затруднили нам переход с Apache 1.3 на Apache 2.0. Данная статья не рассматривает всех проблем, которые могут у вас случиться при переходе на Apache 2.0, но я надеюсь, что она предоставляет ответы на большинство возникающих вопросов и дает вам стартовую точку для будущего «переезда» (а рано или позно он все же должен случиться). Также хочу напомнить, что Apache станет лучше только тогда, когда его пользователи будут помогать разработчикам. Поэтому, если вы обнаружили проблему, которую не можете решить самостоятельно, пожалуйста, оставьте отчет о ней в базе ошибок на http://bugs.apache.org.
Ryan Bloom, перевод Максима Сипягина
Сетевые решения. Статья была опубликована в номере 08 за 2006 год в рубрике sysadmin
