Как создать "ударопрочный" Web-узел: советы профессионалов

Практические рекомендации по предотвращению перегрузки Web-сервера

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

Если Web-узел жизненно необходим для вашего предприятия, он должен выдерживать очень большие нагрузки, не замедляя своей работы, (а о полном отключении и речи быть не может). Поскольку число запросов к типичному Web-узлу ежемесячно возрастает в 2-10 раз (а бывает, что за 3-6 месяцев оно может увеличиться и в 100 раз), нет ничего удивительного в том, что с узлом начинает происходить неладное.

В ответ на возрастающую нагрузку администраторы узлов применяют различные уловки и методы, позволяющие поддержать работоспособность системы. Для этого можно использовать настраиваемые очереди и различные параметры; можно также проводить недорогие и несложные модернизации оборудования, а также применять специализированные продукты, которые позволяют распределить возросшую нагрузку между несколькими компьютерами, - LocalDirector компании Cisco, Net Dispatcher фирмы IBM(ранее называвшийся ShockAbsorber) и другие.

Настройка и "отсечение" лишнего

Перед тем как начать бросаться деньгами, убедитесь в том, что системы, которые вы уже используете в качестве Web-серверов, грамотно настроены и неспособны на большее. "Убедитесь, что установленный размер очереди Listen Queue составляет не менее 128", - советует Роберт Эндрюс, администратор Web-узла и директор фирмы Netscape. Размер очереди Listen Queue определяет максимальное число запросов на соединение, которое может "запомнить" операционная система, прежде чем программа Web-сервера будет готова к их обработке. По заполнении очереди все последующие запросы будут игнорироваться.

Как считает Эндрюс, во многих операционных системах этот параметр часто установлен по умолчанию на слишком малое значение. Проблему усложняет способность многих браузеров параллельно запрашивать сразу несколько соединений с одним сервером, например отдельно для текстового и графического содержимого страницы. "Благодаря одной только правильной установке Listen Queue вы сможете повысить производительность с полумиллиона обслуживаемых в день запросов до 2-3 миллионов", - говорит Эндрюс.

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

Стратегическая модернизация

Сколь бы искусно вы не настраивали вашу систему, рано или поздно ее конфигурация устареет и вам придется ее модернизировать. Перед тем как вытащить свой "киберкошелек", хорошенько подумайте, на что именно лучше всего потратить деньги. "Зачастую люди не понимают одной простой, но важной вещи: в большинстве случаев ограничивающим фактором служит вовсе не мощность процессора, - разъясняет Дейн Эткинсон, президент компаниии SenseNet. - У нас было пять серверов с сетевыми платами на 10 Мбит/с, и когда мы подключили еще один сервер с платой на 100 Мбит/с, его производительность оказалась большей, чем у всех остальных вместе взятых. В недостатке мощности были виновны сетевые платы, а не процессоры. В другой раз у нас перестал справляться с нагрузкой Sun SPARC10 с 32 Мбайт оперативной памяти. Мы довели объем его памяти до 128 Мбайт, и все стало замечательно работать, а нам не пришлось покупать новый компьютер".

Эндрю Макрэй, главный инженер компании The Internet, отмечает по этому поводу: "Обычно люди заботятся только о пропускной способности, не учитывая числа соединений, или думают о мощности процессора, забывая про скорость доступа к диску. Однако на практике быстрый диск, как правило, имеет большее значение, чем быстрый процессор. Если же ваши пользователи имеют медленные модемы, то независимо от мощности сервера на загрузку больших файлов будет уходить много времени". Это снова указывает на необходимость поддержки большого числа соединений.

"В последние месяцы, благодаря реализации "потоков" (нескольких параллельных процессов внутри одной задачи) в сетевых ОС и программном сервере Netscape 2.0, их производительность повысилась на порядок", - говорит Эндрюс из компании Netscape, имея в виду ОС Unix и Windows NT. Подобные улучшения позволят резко сократить расходы на содержание многих Web-узлов.

Повышайте мощность лишь там, где это необходимо

Опытные создатели Web-узлов научились макетировать страницы так, чтобы обеспечить наибольшую эффективность их загрузки и максимальную информативность для пользователя еще в начале прорисовки на экране. Администраторы Web-узлов поняли также, что распределение серверного программно-аппаратного обеспечения должно быть хорошо спроектированным и что самые очевидные решения - не всегда правильные. "Часто бывает, что вы предполагаете наибольшую нагрузку в одном месте, а она оказывается совсем в другом", - поясняет Эткинсон из фирмы SenseNet. В качестве примера он рассказывает о случае, когда SenseNet передавала по RealAudio концерт Деборы Хэрри и Джоан Джетт. "Мы сконфигурировали большую часть аппаратного обеспечения как серверы RealAudio, - рассказывает Эткинсон. - Однако когда к основной странице Web-сервера подключилось несколько тысяч пользователей, нагрузка стала такой высокой, что страницы перестали обслуживаться". Самым простым решением этой проблемы явилось переключение нескольких серверов RealAudio на обслуживание главной страницы.

Правило избыточности

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

Вскоре появятся продукты, которые облегчат задачу управления пропускной способностью для обслуживания запросов пользователей Internet к Web-узлам. К числу подобных систем относится, например, еще не получивший имя продукт компании Packeteer. Управление будет производиться с учетом скорости соединения, вида приложения и IP-адреса.

Как уже отмечалось, компаниям с крупными Web-узлами, таким как CNET, приходится работать с несколькими провайдерами. Это относится, в частности, к фирме BBN Planet, предоставляющей услуги по связи с Internet и Web-хостингу. Для обеспечения высокой производительности и надежности BBN реализовала избыточность каналов на нескольких уровнях. "Web-серверы подключены к кольцу FDDI, которое, в свою очередь, имеет несколько соединений T3 с Internet", - говорит Ларри Томпсон, менеджер сервисных линий из службы Web Advantage Hosting компании BBN Planet.

BBN Planet, владеющая двумя "Web-фермами" в Массачусетсе и Калифорнии, предлагает своим заказчикам возможность создания "зеркальных" Web-узлов в обоих штатах в целях повышения надежности. Поскольку создание "зеркальных" узлов - довольно дорогое удовольствие, его могут позволить себе далеко не все компании. Одной из тех, кому это недоступно, является компания Los Angeles Times. В начале октября в Стэнфордском университете вышел из строя сначала основной, а затем и резервный источник энергоснабжения, и Web-ферма BBN Planet, находящаяся на Западном Побережье, отключилась. В связи с этим незеркалируемый Web-узел Los Angeles Times был недоступен по меньшей мере в течение шести часов.

Распределение нагрузки

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

Самой большой известностью в Internet пользуется метод распределения нагрузки, называемый Round-Robin DNS. Это функция утилиты TCP/IP BIND, используемой для назначения сокетов каждому из запросов на процесс. Как можно понять из названия ("round robin" - серия, последовательность), эта функция позволяет так сконфигурировать список IP-адресов, чтобы запросы последовательно распределялись сервером имен доменов между машинами (или процессами на одной машине), обозначаемыми отличными друг от друга номерами.

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

Другим, более эффективным, вариантом является кластеризация - объединение нескольких машин в кластер с единой файловой системой, выполняемое посредством стандартных или разработанных на заказ инструментов. В частности, возможностью кластеризации обладает ОС VMS компании Digital. Именно поэтому многие администраторы Web-узлов избрали VMS в качестве серверной ОС, которая работает на компьютерах Digital Alpha и более старых VAX. "Кластеризация VMS обладает очень высокой производительностью и надежностью. Она способна обрабатывать огромное число запросов и, будучи правильно сконфигурированной, никогда не выходит из строя", - говорит Джоел Снайдер, старший партнер из компании Opus One, проводивший тестирование производительности различных Web-серверов.

В настоящее время в качестве платформы для внутренних Web-серверов и клиентских узлов в Opus One используют три компьютера Alpha (каждый стоимостью по 3 тыс. дол.) Поскольку функция кластеризации является частью VMS, "она срабатывает автоматически, - говорит Снайдер. - Отказоустойчивость оборудования обеспечивается производителем. Unix-системы тоже можно так настроить, но на это придется потратить определенные усилия".

Другие производители предлагают (или вскоре начнут предлагать) уравновешивающее нагрузку ПО, которое распределяет обработку между несколькими Web-серверами. Здесь можно выделить NetDispatcher компании IBM, LocalDirector компании Cisco, HydraWEB компании HydraWEB Technologies и Web Server Director (WSD) компании Rad Network Devices.

Некоторым из этих продуктов, в особенности HydraWEB и LocalDirector, требуется специальное аппаратное обеспечение. Другие (NetDispatcher, например) поддерживают несколько серверных платформ. Первоначально NetDispatcher был разработан для AIX RISC System/6000s, и IBM собирается перенести его на все популярные платформы. Продукты различаются и в других отношениях: HydraWEB обрабатывает только запросы HTTP, а LocalDirector и NetDispatcher поддерживают все сервисы TCP/IP, включая FTP, электронную почту, telnet, Gopher,CGI-bin и трафик маршрутизаторов с брандмауэрами.

"Одна копия LocalDirector способна обеспечить совместное использование одного виртуального IP-адреса сразу тысячей серверов и распределить между ними обработку, принимая в расчет нагрузку на каждый из них", - говорит Брет Каннингхэм, руководитель работ по выпуску и реализации LocalDirector (см. рисунок). Cisco предназначила свой продукт для рынка промышленных предприятий, крупных сетей intranet и "суперкомпаний" вроде Netscape.

В Viacom, например, используется пять серверов Challenge S компании SGI, которые в среднем обрабатывают около 100 тыс. запросов в день. Благодаря LocalDirector, серверы способны справиться с нагрузкой, примерно в 70 раз превышающей указанную. "Когда проходили бои Майка Тайсона (просмотр которых оплачивался удаленными зрителями), мы обслуживали по 300 тыс. запросов в час, в том числе множество запросов на двух-трехминутные сессии, в течение которых люди делали ставки на предполагаемого победителя", - рассказывает Плэстрик.

NetDispatcher позволяет распределять запросы по серверам, учитывая вид процесса, нагрузку на систему и тип данных. Если верить файлу часто задаваемых вопросов по NetDispatcher, помещенному на Web-узле AlphaWorks компании IBM, "обеспечиваемая продуктом пропускная способность почти в четыре раза выше, чем у Round-Robin DNS".

Во время летних Олимпийских игр 1996 г. в Атланте одна копия NetDispatcher перенаправляла запросы между 70 хостами, расположенными в 5 точках земного шара и объединенными файловой системой Distributed Filing System компании TransArc. "В пиковые периоды обрабатывалось до 17 млн запросов в день, в том числе запросы на сессии RealAudio длительностью в час и более, на изображения в формате JPEG и на массу другой информации, - вспоминает Герни Хант, сотрудник научного отдела исследовательского центра IBM. - В общей сложности за те две недели было обработано 180-190 млн запросов".

Помощь со стороны пользователей

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

Например, благодаря применению JavaScript, компания Netscape смогла предоставить пользователям возможность описания персонифицированных версий базовой страницы и доступа к ней (по адресу personal.netscape.com). "Без JavaScript это было бы невозможно", - говорит Эндрюс из Netscape. Благодаря использованию приложений, написанных на JavaScript, 95% обработки переносятся с серверов Netscape на пользовательские системы. "Если бы обработка запросов к pesonal.netscape.com проходила на серверах компании, нам бы понадобилось еще 100 машин SGI, которые бы работали с полной загрузкой, - говорит Эндрюс. - Задача управления системами и сетью усложнилась бы до невозможности. Если бы обработка выполнялась у нас, эта услуга не могла бы быть бесплатной, ".

Грядут ли улучшения?

На горизонте появились и другие разработки, способные повысить производительность Web-серверов.

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

Эндрюс из Netscape возлагает большие надежды на версию FTP с функцией подсоединения частей файлов. "Такой вариант FTP существенно понизит нагрузку на наши серверы, позволив множеству пользователей избежать повторной загрузки частей файлов, которые они уже получили", - говорит он. Данная функция уже присутствует в спецификации FTP, но пока реализована не во всех FTP-клиентах и серверах. Ее поддерживает, например, NcFTP - командный FTP-клиент для Unix, бесплатно распространяемый по Internet.

Итак, как видите, для защиты Web-узла от действия закона Фудда вы можете (и должны) сделать многое. Всегда лучше заранее наращивать мощность, чем впоследствии наверстывать упущенное. Это, конечно, обойдется недешево, но лучше уж потратить деньги с толком, чем выбросить их на ветер, потерпев простои.

Практические рекомендации по предотвращению перегрузки Web-сервера

Если не наблюдать за кипячением молока, оно убежит; если не наблюдать за работой Web-узла, она может прекратиться. "Эти системы представляют собой сложные механизмы. Чтобы постоянно быть осведомленным о качестве обслуживания и вовремя устранять неисправности, вам придется уделять внимание множеству тонких деталей, - говорит Джонатан Розенберг, вице-президент по технологиям компании CNET. - Мы применяем программы, которые полностью отслеживают деятельность наших серверов. Мы также учитываем почти все жалобы, поступающие от пользователей".

В электронной службе занятости The Monster Board таким образом удалось вовремя узнать об угрозе нехватки дискового пространства. "На узлах вроде Monster Board, где накапливается пользовательская информация, необходим тщательный контроль, - говорит Эрик Роуз, программист из Net Daemons Associates, разрабатывавшей ПО Web-узла для службы занятости. - Когда на диске не хватает места, может произойти долговременный простой".

• "Будьте готовы к росту, - советует Розенберг. - Мы создавали систему, предвидя увеличение на несколько порядков. Это урок, который мы усвоили с самого начала".
• "С самого начала создавайте более крупную систему, чем надо, - советует Майкл Силтон, президент The Virtual Corporation. - Это обойдется дешевле, чем эксперименты с настройкой, регулярные анализы производительности и устранение неисправностей; кроме того, при застраивании системы на 50% и более сверх необходимости, достигается более высокая производительность. Таким образом вы обеспечите стабильность обслуживания своих клиентов, застрахуетесь на будущее, и создадите своему узлу хорошую репутацию благодаря его высокой производительности".
• Лучше использовать не один большой компьютер, а много малых серверов класса Pentium, Alpha или SPARC. "Применение множества малых компьютеров - более экономичное и гибкое решение, чем использование небольшого числа крупных систем", - отмечает Розенберг.
• "Структура внутренней сети узла имеет гораздо большее значение, чем канал связи с Internet, - утверждает Стив Плэстрик, вице-президент по техническому обеспечению интерактивных услуг компании Viacom. - Мы обладаем двумя линиями T-1, и собираемся модернизировать их до T-3; 9 Мбит/с - это не такая уж и высокая пропускная способность. Во внутренней сети мы используем коммутатор Catalyst 5000 компании Cisco".
• Регулярно перепроектируйте свой Web-узел. The Monster Board, например, за два года претерпевала изменения шесть раз. Каждая версия содержала ряд существенных изменений и обновлений в архитектуре узла, интерфейсе, применяемых технологиях, аппаратном и программном обеспечении. В самую последнюю версию включены база данных Oracle и механизм поиска Verity.
• "Системы подсказки, запускаемые по вызывам CGI, лучше писать на компиляторах, например, на C или C++, - говорит Роб Райш, старший научный сотрудник The Internet Co. При использовании интерпретаторов вроде PERL или TCL, скрипт компилируется каждый раз при вызове, что заметно снижает производительность. Вместо использования вызовов CGI, которые требуют обращения к ОС, советую написать для вашего HTTP-сервера аналогичные им внутренние функции. Некоторые профессиональные HTTP-серверы позволяют использовать динамически загружаемые библиотеки, благодаря чему вам не придется модифицировать основную программу".