RDM/2 : Администрирование Интернет-узлов с высокой нагрузкой

	The Russian Electronic Developer Magazine
	Русский электронный журнал разработчика

Администрирование Интернет-узлов с высокой нагрузкой

Dan Mosedale, William Foss, and Rob McCool - Netscape Communications.
Перевод - Дмитрий Максимович (MaximDim)
Оригинал статьи можно было найти на странице Dan Mosedale (http://people.netscape.com/dmose/)

Резюме.

Обеспечение доступа к сервисам WWW и FTP при небольшой нагрузке является хорошо изученным и решенным вопросом. Однако простое масштабирование до уровня миллионов соединений в день способно очень легко привести ваши серверы и сети в состояние шока (в оригинале сказано еще лучше: "can easily push multiple machines and networks to the bleeding edge" - Прим. переводчика). В этой статье мы даем конкретные рекомендации которые помогли нам достичь наилучшей производительности. Наш анализ затрагивает в основном WWW-сервис, но многое из сказанного может быть с равным успехом применено к сервису FTP. В дополнение мы обсудим некоторые инструменты, используемые нами для повседневного управления.
Мы не располагаем обширной статистикой о том как именно каждое изменение конфигурации помогло нам. Скорее, эта работа является результатом наших многочисленных повторений цикла "нагрузка выросла; начались различные сбои; исправляем проблему". Нашей целью является помочь читателю настроить высокопроизводительный, управляемый сервер и дать некоторые идеи о том что делать, когда этот сервер станет испытывать перегрузку.

Наш узел.

Интернет-узел Netscape Communications, на наш взгляд, является одним из самых загруженных узлов в Интернет. Наши сервера обрабатывают в сумме от шести до девяти миллионов HTTP обращений в день. Кроме того, мы сделали наш вэб-браузер, Netscape Navigator, доступным к загрузке с наших серверов через FTP и HTTP [1].

Интернет-узел [2] содержит онлайновую документацию к Netscape Navigator, маркетинговую информацию обо всех наших продуктах, множество страниц общего назначения, включая многочисленные каталоги и так же, домашние страницы сотрудников Netscape. На всех серверах используется Netscape Server, но большинство стратегий, описанных в данной работе, с равным успехом могут быть применены и к другим серверам HTTP и FTP.

В разное время мы пытались использовать различные конфигурации машин и различные операционные системы; Таблица 1 даст вам представление о них.

Таблица 1. Испытываемые компьютеры и ОС.

Sun uniprocessor (60 Mhz) SPARCserver 20
Solaris 2.3 ~2.4

SGI 2-processor Challenge-L
IRIX 5.2

SGI Indy (150 Mhz)
IRIX 5.2 ~5.3

SGI Challenge-S (175 Mhz)
IRIX 5.3

HP 9000/816
HP-UX 9.04

90 Mhz Pentium PC
Windows NT 3.5

90 Mhz Pentium PC
BSD/OS 2.0

*Таблица 1.* Испытываемые компьютеры и ОС.
Sun uniprocessor (60 Mhz) SPARCserver 20	Solaris 2.3 ~2.4
SGI 2-processor Challenge-L	IRIX 5.2
SGI Indy (150 Mhz)	IRIX 5.2 ~5.3
SGI Challenge-S (175 Mhz)	IRIX 5.3
HP 9000/816	HP-UX 9.04
90 Mhz Pentium PC	Windows NT 3.5
90 Mhz Pentium PC	BSD/OS 2.0

Каждый из наших WWW-серверов имеет одинаковое содержимое (подробнее об этом далее). Еще до того, как Netscape Navigator был выпущен и стал доступен для всего сообщества Интернет, мы в своих обсуждениях затрагивали вопрос распределения нагрузки между несколькими серверами, когда это станет необходимо. Так как уже были известны определенные проблемы с использованием для этой цели серверов DNS (DNS round-robin techniques) [3], мы решили реализовать схему случайного выбора адреса внутри самого Netscape Navigator. Короче говоря, когда пользователь Navigator'а вводит адрес home.mcom.com или home.netscape.com браузер обращается к DNS серверу с запросом адреса узла в виде homeX.netscape.com, где X является случайным числом в диапазоне от 1 до 16. В свою очередь, каждый из наших серверов имеет определенное число псевдонимов (alias) homeX указывающих на него. Но так как такая стратегия не применима в большинстве случаев для других интернет-узлов, мы не будем уделять здесь ей больше времени.

Другая схема, которую мы рассматривали - распределение нагрузки с использованием DNS (namessever-based load balancing). Эта схема основана на том, что сервер имен периодически опрашивает каждый WWW-сервер для определения текущей загрузки (в более простом варианте можно использовать статические веса). Затем сервер имен отвечает на запрос об адресе хоста, возвращая IP-адрес наименее загруженного WWW-сервера. Эта схема дополнительно позволяет избежать посылки клиентом запроса к серверу не доступному в данный момент (в отличие от схемы "DNS round-robin techniques" - Прим. переводчика). Однако, необходимо учесть, что неработающий сервер может оставаться в пуле серверов на период времени DNS TTL. Еще две схемы, которые мы планируем рассмотреть в будущем - RFC 1794 [4] и lbnamed [5].

Таблицы 2 и 3 обобщают некоторую статистику производительности для различных серверов на день 26 Июля 1995 года в соответствии с присвоенными каждой машине относительными весами. В нашем случае мы давали каждой машине весовой коэффициент в шестнадцатых долях от полной загрузки нашего узла.

Замечание: В дополнение к 1/16 доли WWW-нагрузки машина SGI 150 Mhz R4400 Indy обслуживала адреса www.netscape.com и home.netscape.com и эта машина обрабатывала все CGI-процессы для нашего узла. Общая нагрузка CGI на этот день составила 49,887 запросов из общего количества в 1,548,869 HTTP-запросов (подробнее об этом далее).

Таблица 2. Активность WWW-серверов
в период 25/07/95 23:58:04 и 26/07/95 23:58:59

Компьютер
Доля нагрузки
Обращений
Перенаправлений
Ошибок
Уник. URL
Уник. хостов
Передано кб.

SGI 150 Mhz R4400 Indy
1/16
1,548,859
68,962
7,253
4,558
120,712
12,487,021

SGI 175 Mhz R4400 Challenge S
6/16
2,306,930
47,154
23
2,722
249,791
11,574,007

SGI 175 Mhz R4400 Challenge S
5/16
2,059,499
43,441
43
2,681
225,055
10,626,111

BSD/OS 90 Mhz Pentium
4/16
1,571,804
31,919
23
2,351
192,726
7,936,917

*Таблица 2.* Активность WWW-серверов
в период 25/07/95 23:58:04 и 26/07/95 23:58:59
Компьютер	Доля нагрузки	Обращений	Перенаправлений	Ошибок	Уник. URL	Уник. хостов	Передано кб.
SGI 150 Mhz R4400 Indy	1/16	1,548,859	68,962	7,253	4,558	120,712	12,487,021
SGI 175 Mhz R4400 Challenge S	6/16	2,306,930	47,154	23	2,722	249,791	11,574,007
SGI 175 Mhz R4400 Challenge S	5/16	2,059,499	43,441	43	2,681	225,055	10,626,111
BSD/OS 90 Mhz Pentium	4/16	1,571,804	31,919	23	2,351	192,726	7,936,917

Таблица 3. Пять самых загруженных минут
за тестируемый интервал времени.

Компьютер
Доля нагрузки
Bytes/Hits
Bytes/Hits
Bytes/Hits
Bytes/Hits
Bytes/Hits

SGI 150 Mhz R4400 Indy
1/16
430,600/82
345,132/61
227,618/61
224,849/60
236,678/59

SGI 175 Mhz R4400 Challenge S
6/16
613,621/119
646,112/119
656,412/110
545,699/108
520,256/107

SGI 175 Mhz R4400 Challenge S
5/16
466,244/93
430,870/88
358,186/84
375,964/84
531,421/82

BSD/OS 90 Mhz Pentium
4/16
375,696/81
256,143/77
417,655/76
394,878/72
298,561/70

*Таблица 3.* Пять самых загруженных минут
за тестируемый интервал времени.
Компьютер	Доля нагрузки	Bytes/Hits	Bytes/Hits	Bytes/Hits	Bytes/Hits	Bytes/Hits
SGI 150 Mhz R4400 Indy	1/16	430,600/82	345,132/61	227,618/61	224,849/60	236,678/59
SGI 175 Mhz R4400 Challenge S	6/16	613,621/119	646,112/119	656,412/110	545,699/108	520,256/107
SGI 175 Mhz R4400 Challenge S	5/16	466,244/93	430,870/88	358,186/84	375,964/84	531,421/82
BSD/OS 90 Mhz Pentium	4/16	375,696/81	256,143/77	417,655/76	394,878/72	298,561/70

Инструменты.

Размер нашего интернет-узла и нагрузка на него росли очень быстро, и мы собрали набор инструментов которые помогают нам управлять серверами и их содержимым. Мы использовали некоторое количество уже существующих программ, некоторые из них были нами улучшены, и несколько было разработано. Многие из используемых программ мы здесь не станем упоминать, а сосредоточимся на тех инструментах, которые могут быть непосредственно полезны при управлении WWW-серверами и их содержимым. Мы хотим избежать дискуссии о средствах создания HTML документов; тек кто интересуется этим, мы советуем заглянуть на http://home.netscape.com/home/how-to-create-web-services.html, где содержится множество ссылок на такие программы.

Контроль версий документов: CVS.

В связи с тем, что содержимое нашего сервера пополняется из нескольких разных источников внутри нашей компании, мы решили использовать систему контроля версий CVS [6] для управления деревом документов. Система работала в целом не плохо, но не являлась идеальным решением для нашего случая.

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

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

Распространение содержимого.

Раз уж мы решили использовать несколько компьютеров для обслуживания нашего WWW-сервера, стоит подумать о приемлемом механизме синхронизации содержимого дерева документов нашего мастер-сервера на остальные сервера. Например, NCSA распределяет документы между серверами используя для хранения содержимого дерева документов распределенную файловую систему AFS [3].

Для нас было очевидно, что существует другое решение этой проблемы, rdist [7] - программа специально спроектированная для синхронизации дерева файлов. Однако, мы чувствовали, что не сможем использовать эту программу без ее модификации, так как вся ее система безопасности основывается исключительно на файлах .rhosts, а это слишком слабый уровень безопасности. Поэтому, с помощью некоторых других разработчиков, мы работали над добавлением SSL (Secure Socket Layer - Прим. переводчика) в rdist для обеспечения как шифрования передаваемых данных, так для лучшей идентификации обоих сторон. При использовании протокола SSL нам больше нет необходимости полагаться на IP адрес клиента для определения его полномочий, вместо этого используются шифрованные сертификаты.

В процессе работы над добавлением протокола SSL в rdist мы решили, что будет разумно использовать последнюю версию rdist от USC, в частности потому, что в этой версии имелась возможность использовать в качестве транспорта rsh(1) вместо rcmd(1). А так как rsh не использует rcmd в своей работе, то отпала необходимость изменять эффективные права процесса на права суперюзера (setuid root), что являлось еще одним существенным улучшением безопасности системы. Интересным побочным эффектом этой работы явилось то, что мы получили SSL версию rsh(1), которую мы стали использовать для копирования файлов регистрации (log files).

Мониторинг работы.

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

Программа проверки времени отклика спроектирована для работы с внешней, по отношению к WWW-серверу машины. Периодически, она запускается и посылает HTTP-запрос на WWW-сервер за некоторым документом. И измеряет промежуток времени от начала этого процесса до его конца, то есть, от вызова функции connect() до возврата нуля функцией read(), что означает закрытие сеанса со стороны сервера. Если вы выберите для этой процедуры относительно небольшой документ, то измеренное время будет хорошим индикатором того, как долго пользователи ожидают ответа сервера (так как в идеале небольшой документ должен быть получен практически моментально) (здесь, естественно, пропускная способность каналов связи предполагается достаточной, чтобы не являться дополнительным ограничивающим фактором -Прим. переводчика). В нашем конкретном случае, мы запускаем этот монитор на удаленной машине, имеющей надежное соединение с Интернет, и на машине находящейся в нашей локальной сети. Это дает возможность увидеть, что является причиной потери производительности - перегрузка сети или перегрузка сервера.

Программа-анализатор лог-файлов, которая теперь входит в состав стандартной поставки серверов Netscape Communications and Commerce server, предоставляет, например, информацию о наиболее загруженных часах и минутах дня, и о том какой процент документов загружается из кеша. Этот анализатор очень полезен, для определения часов наибольшей нагрузки, требующих повышенного внимания. Так как наш интернет-узел обрабатывает очень большой траффик, мы спроектировали анализатор лог-файлов, способный очень быстро обрабатывать большие объемы информации.

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

Если мы знаем, что не сможем прийти и перегрузить сервер, мы используем на компьютере выключатель питания, управляемый через последовательный интерфейс RS-232 для жесткой перезагрузки сервера в случае его сбоя. Таким образом, небольшой PC компьютер, с двумя последовательными портами, достаточен для индивидуального мониторинга 10 систем и обеспечения автоматического восстановления работы в большинстве случаев некритических сбоев в работе серверов (т.е. в случае проблем, не связанных с поломкой железа или переполнением раздела диска лог-файлами).

Производительность.

Предыдущие работы [9,10,11], в которых исследовалась производительность протокола HTTP пришли к выводу, что HTTP в своем современном виде, да и сам TCP плохо ориентирован на достижение хорошей производительности. Авторы некоторых из этих работ предложили ряд мер по улучшению данной ситуации через изменения в протоколе. В настоящее время однако, нам более интересен вопрос о достижении максимальной производительности с использованием существующих протоколов.

Не удивительно, что существующие реализации стека TCP плохо переносят работу в условиях высокой нагрузки, просто они никогда не попадали ранее в такие условия. Стандартная, для ОС семейства UNIX модель обработки новых соединений при помощи системного вызова fork очень плохо масштабируется, и в частности из-за этого Netscape Server использует модель пула процессов (process-pool model) (аналогичная схема используется сейчас и в популярном http-сервере Apache-Прим. переводчика).

Ядра ОС

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

Настройка TCP

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

Размер очереди соединений (listen queue), который определяет максимальное количество соединений, поставленных ядром в очередь на обслуживание (connections pending by kernel). Соединение считается поставленным в очередь, когда оно не было до конца установлено или было установлено и ожидает в системном вызове accept(2). Если размер этой очереди слишком мал, клиенты начинают получать сообщения "отказ в соединении" ("connection refused") или "время ожидания истекло" ("connection timed out"). Если же размер этой очереди слишком велик результаты могут быть случайными: некоторые ОС продолжают функционировать как обычно, в то время как производительность других существенно падает. Вам необходимо поэкспериментировать с этим параметром, для нахождения его оптимального значения. Версия 1.1 сервера Netscape Communications and Commerce Server никогда не требует размера очереди соединений больше 128.

В реализациях стека TCP, ведущих свою историю от TCP стека BSD (BSD-based TCP stack), размер очереди соединений контролируется параметром SOMAXCONN. Исторически, этот параметр чаще всего задается при помощи директивы #define в модулях ядра, так что если у вас нет доступа к исходному коду ядра ОС, вам скорее всего необходимо получить патч от производителя этой ОС для решения данной проблемы. В ОС Solaris, данный параметр называется tcp_conn_req_max и может запрашиваться и устанавливаться при помощи утилиты ndd(1M), применяемой к устройству /dev/tcp. Компания Sun, производитель ОС Solaris, ограничила верхний предел изменения параметра tcp_conn_req_max таким способом числом 32. Обратитесь к компании Sun, для нахождения возможности повышения этого предела в будущем.

Дополнительно, ядро ОС должно располагать достаточным объемом оперативной памяти, для обеспечения буферизации всех посылаемых данных. В ОС, использующих BSD-версию стека TCP эти буферы называются mbuf. Количество mbuf, установленное по умолчанию в большинстве ядер ОС слишком мало, для обслуживания большого трафика, и требуется настройка этого параметра. Мы установили, что опять же, лучшим методом определения оптимального значения этого параметра для конкретной ОС, является метод проб и ошибок. Если команда netstat -m показывает, что запросы на выделение памяти не удовлетворяются, скорее всего необходимо увеличить число mbuf. В ОС IRIX параметр, который необходимо увеличить называется nm_clusters и находится в файле /var/sysgen/master.d/bsd.

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

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

Однако для WWW-сервера несколько часов это слишком большое время. Если клиент не посылает информацию серверу в течении нескольких минут, то скорее всего клиент стал недоступен. В прошлом, ошибки маршрутизаторов часто становились причиной недоступности хостов. В современном Интернет эта проблема тоже актуальна, наряду с увеличившимся числом пользователей, которые используют протоколы SLIP и PPP для соединения с сетью. Опыт показывает, что такие типы соединений являются не надежными и могут служить причиной ситуаций когда машины внезапно становятся недоступными. Большинство HTTP-серверов настроены на период ожидания данных от клиента порядка нескольких минут, после чего соединение принудительно закрывается.

Если команда netstat -an показывает много сокетов в состоянии IDLE, или много ожидающих HTTP серверов, вы должны для начала проверить, устанавливается ли опция SO_KEEPALIVE. Затем надо проверить, допускает ли ваша ОС изменение интервала между посылками пакетов keepalive. Многие ОС, такие как IRIX и Solaris предоставляют механизмы для изменения этого интервала с часов до минут. Большинство ОС, исследованных нами, имели установленный по умолчанию интервал 2 часа; мы обычно уменьшали его до 15 минут. Если ваша система не является выделенным WWW-сервером, можно рассмотреть вопрос о большем интервале, для того, чтобы неактивные telnet-сессии не увеличивали непроизводительный сетевой трафик. И третья вещь, которую необходимо проверить - поддерживает ли реализация стека TCP в вашей ОС закрытие сокета из-за таймаута во время стадии завершения соединения. Дело в том, что некоторые BSD-версии стека TCP, на которых основаны многие современные ОС, не используют механизм keepalive во время процедуры закрытия соединения. Это означает, что соединение с удаленным хостом, который становится недостижимым во время процедуры закрытия соединения, не закрывается по тайм-ауту и остается открытым. Если вы заметите подобную ситуацию, обращайтесь к производителю вашей ОС за исправлением (patch).

Разработчик вашей ОС - Ваш друг; Или о значении patch'ей.

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

На сегодняшний день (не забывайте, что данная статья увидела свет в 1995 году-Прим. переводчика) доступны исправления, увеличивающие размер очереди соединений для IRIX 5.2 и 5.3, так же включающие поддержку таймера keepalive на этапе закрытия соединения. Эти исправления так же устраняют некоторые другие проблемы, относящиеся к многопроцессорным конфигурациям и производительности. Обращайтесь в компанию SGI за текущими номерами patch'ей; если вы используете систему WebFORCE, скорее всего эти исправления уже есть в вашей системе. При этом, большинство параметров нуждающихся в настройке, находятся в файле /sysgen/master.d/bsd.

Если вы используете Solaris 2.3, вам абсолютно необходимо использовать patch 101318. Кроме того, мы обнаружили, что версия 2.4 ОС Solaris способна обслуживать гораздо более высокую нагрузку на стек TCP чем версия 2.3 с наложенными patch'ами. Поэтому, если имеется возможность, мы рекомендуем вам произвести обновление ОС до версии 2.4, особенно, если нагрузка на ваш интернет-узел стала приближаться к уровню нескольких сотен тысяч запросов в день. И не забудьте наложить патч 101945 на версию 2.4.

Лог-файлы.

Общий принцип - чем меньше информации записывается в лог-файлы, тм выше производительность. Мы обнаружили, что полностью отключив ведение лог-файлов можно добиться повышения производительности примерно на 20%. В будущем, многие WWW-серверы, скорее всего, будут предоставлять возможность ведения лог-файлов в альтернативных форматах, отличных от "общего формата лог-файлов" ("common log format"), принятого в настоящее время, которые смогут обеспечить как более высокую производительность, так и возможность записи только той информации, которая необходима администратору сервера.

Многие WWW-сервера позволяют производить определение доменного имени клиента по его ip-адресу (reverce DNS lookup). Не смотря на то что это весьма полезная информация, если заставлять WWW-сервер заниматься этим в процессе работы, это может привести к существенному снижению производительности. Причиной этого служит то, что запросы к DNS-серверу часто выполняются очень медленно или вообще заканчиваются тайм-аутом. При этом увеличивается трафик в вашей сети и расходуются некоторое (часто нетривиальное) количество сетевых ресурсов на ожидание ответа от серверов DNS.

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

На нашем интернет-узле, лог-файлы чередуются (rotate) каждые 24 часа. Закрытые файлы сжимаются и помещаются в специальный каталог. Специально выделенная UNIX-машина в нашей сети используя утилиту rsh(1), улучшенную поддержкой протокола SSL, перемещает сжатые лог-файлы со всех машин, на которых работают WWW-сервера в отдельный раздел, емкостью 4 Гб. Там лог-файлы разжимаются, соединяются в один дольшой файл и затем обрабатываются нашим лог-анализатором. Тут же выполняется и определение имен машин клиентов по ip адресам. Это позволяет выполнять только один запрос к DNS-серверу для каждого уникального ip-адреса в течение дня. Весь процесс обработки лог-файлов таким образом занимает порядка одного часа.

Один лог-файл за один день с WWW-нашего сервера, в сжатом состоянии, обычно имеет размер около 70 Мб. Таким образом, за день у нас накапливается примерно 250 Мб информации в лог-файлах. Наш метод манипулирования с лог-файлами позволяет этой системе работать месяцами без внимания со стороны обслуживающего персонала. Один раз в месяц эта информация сохраняется на 8-мм стриммер.

Общий анализ лог-файлов нашего интернет-узла показал следующее:

Пиковая нагрузка на наши WWW-сервера приходиться на период между 12 и 15 часами и достигает 120-140 запросов в секунду на каждую машину. Второй по величине пик, примерно в два раза меньший по амплитуде, приходится на период между 17 и 18 часами.
Самый нагруженный день недели - среда. В среду обрабатывается обычно больше запросов, чем за субботу и воскресенье вместе взятые.

Оборудование.

Сеть.

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

Кстати заметим, что в ОС IRIX имеется нестандартная но очень полезная опция -C утилиты netstat(1), позволяющая просматривать данные, собираемые netstat(1) в полноэкранном формате с динамическим обновлением.

Оперативная память.

Тут все крайне просто: чем больше, тем лучше. Оперативной памяти в машине должно быть достаточно как для буферизации сетевых данных, так и эффективной работы дискового кеша. Эффективность дискового кеша на наших серверах почти всегда находиться на уровне выше 90%. Большинство современных UNIX-систем автоматически изменяют количество памяти, отводимой под кеш, но некоторые ОС могу потребовать ручной установки этого параметра. Многие производители включают в состав своих ОС полезные утилиты мониторинга эффективности работы дискового кеша: ОС, ведущие свою родословную от System V обычно предоставляют для этих целей утилиту sar, в HP/UX есть полезная утилита monitor()1M, а в IRIX - osview(1).

Наша стандартная конфигурация WWW-сервера.

Типичная машина, используемая на нашем интернет-узле в качестве WWW-сервера, представляет собой обычный компьютер класса рабочей станции (например Sun SPARC 20, SGI Indy или Pentium 90 PC), на котором постоянно работает от 128 до 150 процессов. Что касается машин под управлением ОС UNIX, то мы обнаружили, что 128 Мб оперативной памяти обычно более чем достаточно. С таким количеством памяти имеется достаточно места для буферизации сетевых данных, для эффективной работы дискового кеша, и обычно еще имеется несколько мегабайт (а то и десятков мегабайт) свободной оперативной памяти (в зависимости от версии ОС UNIX).

Так же, нами обычно используются жесткие диски (HDD) объемом не менее 1 Гб. Так как сейчас, каждый наш WWW-сервер производит около 200 Мб лог-файлов (в несжатом виде) в день, да и обьем содержимого нашего интернет-узла постоянно растет. Данные полученные с использованием утилиты sar и других инструментов, позволяют сделать вывод, что наши машины проводят в среднем от 5% до 20% времени в ожидании дискового ввода-вывода (disk I/O). Так как эффективность работы дискового кеша уже достаточно велика, мы рассматриваем возможность перемещения лог-файлов на отдельный fast/wide SCSI диск, и собирается дополнительно поэкспериментировать с параметрами файловых систем.

Разное.

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

Немного о безопасности.

В дополнение к обычным соображениям о безопасности узлов в Интернет [12], при обслуживании с WWW-узлов приходится обращать внимание еще на ряд возможностей нарушения безопасности. Одна из наиболее заметных - это CGI программы [13]. Механизм CGI позволяет добавлять очень интересную функциональность WWW-серверам. К сожалению CGI-программы, они могут быть очень большой проблемой с точки зрения безопасности интернет-узла: так как такие программы, в общем случае, воспринимают данные вводимые пользователем вашего WWW-узла, и надо быть очень внимательным при принятии решения о том, что можно делать с этими данными.

К примеру, если CGI-скрипт принимает e-mail адрес, вводимый пользователем и напрямую передает его программе sendmail в качестве аргумента командной строки, и пользователь вместо адреса введет определенную последовательность команд интерпретатора sh, то результаты работы подобного CGI-скрипта могут быть весьма неожиданными. Такого рода неожидаемая интерференция между различными программами - общее место нарушений безопасности. А так как большинство людей, которые хотят использовать CGI-программы на своих WWW-страницах, не являются специалистами по вопросам безопасности в ОС UNIX, то наиболее простым методом решения данной проблемы является просто запрет выполнения CGI-программ из персональных WWW-страниц пользователей.

Однако, можно и не применять таких жестких мер: например, можно использовать интерпретатор taintperl[4] для CGI-скриптов пользователей. Как известно, язык Perl на сегодняшний день является одним из наиболее часто используемых языков при написании CGI-скриптов; Perl исключительно мощный инструмент в области манипуляции с данными разных типов и создания динамических HTML-документов. А taintperl - это версия языка Perl, специально предназначенная для строгого контроля за используемыми данными. Любые данные рассматриваются интерпретатором taintperl как априорно опасные, и не могут быть использованы в сколько-нибудь опасных операциях, если это не разрешено явно (например, при вызове внешних команд с параметрами-Прим. переводчика). Это означает, что такого рода CGI-скрипты могут быть относительно легко проверены лицом, ответственным за безопасность узла на предмет возможных нарушений.

Разнородность платформ для WWW-серверов.

Интересной особенностью нашего интернет-узла является то, что эти условия являются идеальной тестовой площадкой для портирования нашего сервера (Имеется в виду Netscape Communications and Commerce server-Прим. переводчика) на различные платформы. Так как для нас было очевидно с самого начала, что наш сервер будет функционировать на нашем узле на различных платформах, предстояло решить что нам делать с поддержкой CGI программ для разных ОС. После некоторых раздумий мы решили, что непрактично будет пытаться спортировать и отладить все наши CGI-скрипты (и заставлять всех наших пользователей делать тоже самое с их собственными скриптами) на каждую новую платформу, которую мы можем начать использовать. Оказалось, что это решение было принято нами исключительно вовремя, так как сразу же после этого нам пришлось портировать наш сервер на платформу MS Windows NT.

Мы назначили одно имя (alias) машине, на которой будут выполняться все CGI-скрипты нашего интернет-узла. Затем, были разработаны специальные правила для разработчиков наших HTML-документов, по которым все обращения к CGI-скриптам должны были выполняться с использованием данного имени машины (например cgi.netscape.com- Прим. переводчика). Побочный эффект этого решения состоит так же в том, что все CGI-скрипты будут выполняться на одной машине, в одном окружении и машина может быть специальным образом оптимизирована для выполнения скриптов. А так как наш узел состоит из большого числа разнообразных и несовместимых между собой машин, то отпала необходимость поддержки CGI-скриптов на всех платформах, с учетом их специфики. В среднем, каждый день наш интернет-узел обрабатывает порядка 50,000 запросов на исполнение CGI-скриптов (общее количество запросов достигает 7,500,000).

Дополнительно было бы интересно произвести эксперименты с разделением содержимого других типов (например графических файлов), с разносом собственно HTML-документов и графики по разным машинам. В случае необходимости тут может быть использована схема балансировки нагрузок, основаная на DNS (DNS-based load-balancing), о чем уже говорилось выше (например имя gif.netscape.com может быть использовано для обращения к нескольким машинам, чья работа будет состоять только в обслуживании запросов к GIF-файлам).

FTP или HTTP.

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

FTP позволяет использовать механизм "сигнал занято", который сообщает пользователю о том, что узел в данный момент обслуживает слишком много запросов, и запрос пользователя не будет обработан. Это ограничение легко настраивается администратором. HTTP так же предоставляет аналогичный механизм, однако многие HTTP-сервера не используют его так как это легко может привести пользователя в замешательство. Дело в том, что в отличие от FTP, в HTTP нет понятия сессии (sessionless protocol), а используется новое соединение для запроса каждого следующего файла, и поэтому легко может возникнуть ситуация когда программа пользователя удачно получит тело HTML-документа, и не сможет получить графические изображения, содержащиеся в нем. Остается надеяться, что будущие работы в области усовершенствования стандарта HTTP смогут улучшить данную ситуацию.

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

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

Запуская сервисы FTP и HTTP одновременно на одной машине, мы установили, что 128 процессов HTTPD и 50 одновременно активных FTP-соединений - это предел нагрузки для машин используемого класса. Дальнейший рост нагрузки приводит к ошибкам доступа к ресурсам для обоих протоколов. Однако та же машина может без проблем обслуживать 250 активных FTP-соединений если убрать сервис HTTP.

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

Заключение и дальнейшие направления работы.

Не смотря на то, что интернет-узлы подобные нашему в настоящее время являются скорее исключением, мы ожидаем, что вскоре они станут наоборот очень распространены, учитывая взрывообразный рост Интернет. Так же мы ожидаем, что наполнение интернет-узлов станет все более динамичным в будущем, как с внешней стороны (front-end) (такие технологии как server push[14] и Java[15]) так и с внутренней строны (back-end) (использование SQL БД и поисковых механизмов станет все более обычным делом). Все это обещает принести с собой обширное поле для исследований, особенно в области повышения производительности и управляемости.

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

Благодарности.

Особое спасибо Brendan Eich за его способность создавать полезные инструменты (toolsmithing) и за то что он не брезговал пачькать руки исходными текстами ядер ОС, Jeff Weinstein за SSLrsh и SSLrdist, Rod Beckwith за сетевую магию, и Gene Tran за помощь в измерении производительности и профайлер ядра ОС SGI. Спасибо Bill Earl, Mukesh Kacker, Mike Karels и Vernon Schryver за исправления ошибок в реализациях TCP общие полезные советы. Мы так же благодарны за отзывы, поступившие от всех людей, кто уделил свое время прочтению черновой версии этой статьи.

Об авторах.

Авторы ответсвенны за дизайн, воплощение и становление интернет-узла Netscape с момента его возникновения.

Dan Mosedale Lead UNIX Administrator в компании Netscape. Он администрировал различные версии ОС UNIX достаточно долго, чтобы совершенно разлюбить их. Dan любит повозиться со всякими таинственными Интернет-штучками и написал FAQ о том как подключиться к MBONE.

William Foss Web-master в компании Netscape. Его сегодня больше всего интересует, как продвинуть интернет-узел как можно дальше теперь и в экономическом плане. До того, как начать работать в Netscape, он имел завидную работенку - упражняться с большими UNIX-системами и работал вместе с Jim Clark в компании Silicon Graphics.

Rob McCool игрок из команды техников компании Netscape. Он принимал участие в проектировании и разработке Netsite Communications and Commerce servers, В своей предыдущей жизни он так же проектировал, разрабатывал, тестировал, документировал и поддерживал NCSA httpd с самого начала и до версии 1.3.

Библиография.

[1]: http://home.netscape.com/comprod/mirror/index.html
[2]: http://home.netscape.com
[3]: Kwan, T., McGrath, R., ~Reed, D.
"User Access Patterns to NCSA's World Wide Web Server".
[4]: Brisco, T.
"DNS Support for Load Balancing".
RFC 1794, USC/Information Science Institute, April 1995.
[5]: Schemers, Roland J.
"ibnamed: A Load Balancing Name Server in Perl".
LISA IX Conference Proceedings.
[6]: ftp://prep.ai.mit.edu/pub/gnu/cvs-1.5.tar.gz
[7]: Cooper, M.
"Overhauling Rdist for the 90's".
LISA IX Conference Proceedings, pp. 175-188.
[8]: http://home.netscape.com/info/security-doc.html
[9]: Padmanabham, V., ~Mogul, J.
"Improving HTTP Latency".
[10]: Spero, S.
"Analysis of HTTP Performance Problems".
1994.
[11]: Viles, C., ~French, J.
"Availability and Latency of World Wide Web Information servers".
Computing Systems, Vol. 8, No 1, pp. 61-91, USENIX Association.
[12]: When looking for UNIX security information, a couple of excellent places to start are
"http://www.alw.nih.gov/Security/security.html"
and
"http://www.yahoo.com/Computers_and_Internet/Security_and_Encryption/"
[13]: http://hoohoo.ncsa.uiuc.edu/cgi/
[14]: http://home.netscape.com/assist/net_sites/pushpull.html
[15]: java.sun.com

Интересные ссылки: Услуги юриста адвокат юридические услуги.

Комментариев к странице: 0 | Добавить комментарий

Редактор: Дмитрий Бан
Оформление: Евгений Кулешов