Несколько компьютеров для одного Web-сайта

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

Однако наличие отдельного сервера для каждой реплики имеет несколько недостатков. Ручной выбор сервера утомителен для пользователя, особенно при просмотре Web-содержания. В идеале репликация содержания на различных Компьютерах должна быть незаметной для пользователя. Ручной выбор не обязательно равномерно распределяет пагрузку. Отдельный пользователь не осведомлен о решениях, принятых другими пользователями, или о текущей загрузке серверов. Наличие различных доменных имеп для каждой реплики порождает ситуацию, когда несколько URL ссылаются на одно и то же содержание. Рассмотрим Web-страницу bar.html, которая реплицирована на два сервера: wwwl.big.com и www2.big.com. Предположим, что ресурс http://wwwl.big.com/bar.html был сохранен в кэше браузера. В дальнейшем пользователь может выдать запрос на ресурс http://www2.big.com/ bar.html. Однако браузер не знает, что этот URL ссылается на то же самое содержимое и, следовательно, не сможет вернуть кэшированное содержимое.

Использование одного доменного имени для всех реплик устраняет эти проблемы. Однако при этом требуется эффективный способ доставки клиентского запроса к отделыюй реплике. Простейший подход состоит в том, чтобы назначить различные IP-адреса каждой из реплик. Например, www.big.com может быть размещен на двух компьютерах с IP-адресами 10.198.3.47 и 10.198.3.48, соответственно. Преобразование доменпого имени сервера в определенный IP-адрес выполняется сервером доменных имеп (DNS), о чем будет рассказано в главе 5 (раздел 5.3.5). При альтерпагивпом подходе имя www.foo.com может быть ассоциировано с одним IP-адресом, который соответствует серверу-заместителю, расположенному перед комплексом Web-хостинга, как показано на рис. 4.1. Этог сервер-заместитель может принимать решепия, какая реплика будет обрабатывать клиентский запрос. Выбор реплики может основываться на различных критериях, таких как пагрузка на серверы или запрашиваемые URL. В настоящее время ведутся исследования по разработке оптималыюй стратегии выбора реплики, о чем подробнее будет говориться в главе 11 (раздел 11.13).

Рис. 4.1. Хостинговая система с сервером-заместителем перед четырьмя Web-серверами

Репликация одного и того же содержания на нескольких серверах сопровождается рядом проблем. Последовательность запросов от одного и того же клиента может не быть обработана одной и той же репликой. Чрезвычайно важпо, чтобы каждая реплика генерировала один и тот же ответ на один и тот же запрос. Каждый сервер должен иметь однозначное соответствие между URL и содержанием, а также выдавать идентичный HTTP-ответ. Если содержание изменяется, новые данные должны быть доступны от каждой реплики. Если сервер извлекает ресурсы из собственной файловой системы, любое изменение в файле требует обновления каждой реплики. Кроме того, реплики должны иметь одинаковые стратегии управления доступом. Пользователю не должен быть разрешен доступ к ресурсу для одной реплике и запрещен для другой. Это требует, чтобы на каждым сервере имелась одинаковая информация об имени пользователя и пароле, а также одинаковая стратегия управления доступом. Аналогично, если Web-сайт использует cookies, реплики должны иметь соглашение о том, как их генерировать и интерпретировать.

Источник: Web-протоколы. Теория и практика. — M.: ЗАО «Издательство БИНОМ», 2002 г. – 592 c.: ил.

Вы можете следить за любыми ответами на эту запись через RSS 2.0 ленту. Вы можете оставить ответ, или trackback с вашего собственного сайта.

Оставьте отзыв

XHTML: Вы можете использовать следующие теги: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

 
Rambler's Top100