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

…сли что-нибудь хорошенько толкнуть, оно упадет.
‡акон ”удда, ‘борник комедий ’еатра Firesign

‘ тем же успехом это высказывание могло бы относитьсЯ и к 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-узла длЯ службы занЯтости. - Љогда на диске не хватает места, может произойти долговременный простой".