CC BY
36
УДК 004.738.52
ИНТЕРНЕТ-ДОСТУП К WEB-РЕСУРСАМ ГЕОГРАФИЧЕСКИ РАСПРЕДЕЛЕННОЙ СИСТЕМЫ МОНИТОРИНГА БЛИЖНЕГО И ДАЛЬНЕГО КОСМОСА
© 2007 В. Н. Черненков, В. В. Витковский, Н. А. Калинина
Специальная астрофизическая обсерватория, Нижний Архыз, 369167 Россия Поступила в редакцию 17 июля 2007 г. ; принята в печать 19 июля 2007 г.
Проанализированы состояние и скоростные характеристики ШеЬ-доступа к первым пяти базовым узлам проектируемой географически распределённой системы научного мониторинга ближнего и дальнего космоса. Определена возможность создания архитектуры, включающей перенаправление пользовательских запросов на кэширующий сервер. Это позволит существенно разгрузить инструментальные каналы связи и ускорить время установления НТТР-соединений, особенно для узлов,
связанных через загруженные Интернет-каналы.
1. ВВЕДЕНИЕ Схема распределенной системы мониторинга, постановка задачи Проектируемая географически распределенная система мониторинга ближнего и дальнего космоса [1] представляет собой сеть связанных через Интернет мини-обсерваторий, организованных как базовые узлы при университетах, других учебных и научно-исследовательских организациях, заинтересованных в соответствующих наблюдениях. Головной узел сети (Центр) необходимо разместить в месте с наиболее широкополосным и с наименьшими задержками доступом по международным каналам Интернета. Он будет выполнять функции интернет-портала, координирующего выдачу заданий на наблюдения, сбор метеорологической информации и другие задачи, возникающие при управлении распределёной системой мониторинга. Общая схема системы представлена на рис. 1.
Создаваемая система должна обеспечить подготовку и проведение экспериментов на телескопах как из центра сбора и обработки данных, так и прямо с пользовательских терминалов, которые могут быть созданы на рабочих станциях в любой точке земного шара и связаны через Интернет [2, 3]. Типовой узел должен предоставить возможность дистанционного проведения экспериментов и поддерживать информационное взаимодействие между аналогичными узлами [4, 5].
Для конкретизации схемы построения системы, выбора места размещения портала и языковых средств для программных разработок сетевого взаимодействия узлов в гетерогенной операционной среде необходим анализ параметров сетевого доступа к каждому узлу из Интернета.
2. АНАЛИЗ WEB-ДОСТУПА К БАЗОВЫМ УЗЛАМ
Методика и результаты оценки параметров доступа
Основной оценкой качества доступа к Web-серверу базового узла являлось измеренное время установления соединения по HTTP-протоколу. Измерения проводились в автоматическом режиме из 18-ти различных точек Европы, Азии, Северной Америки и Австралии. С помощью специальной программы каждые 0.5 часа посредством Web-сервиса тестовой службы Watch Mouse Web Site Monitoring [6] посылались HTTP-запросы к тестируемым узлам, измеренное время записывалось в файлы протоколов для последующего анализа. На момент написания статьи в распоряжении авторов имелись данные о пяти веб-сайтах, предлагаемых для возможного использования в качестве базовых узлов. Список сайтов и среднее время соединения с ними представлены в таблице. Там же указаны значения корня из оценки выборочной дисперсии произведенных измерений, которые характеризуют стабильность и качество канала.
Подсчет проводился на основе анализа около 250 измерений, выполненных в разное время суток в сентябре—декабре 2006 г. Немногочисленные отскоки отсчётов в измерениях задержки пакетов более 3-х секунд, связанные с возможными пе-реповторами запросов, отбрасывались. Как видно из таблицы, для Гонконга, Сингапура и Австралии на конец 2006 года задержка превышает 320 мс независимо от тестируемого узла, что вероятнее
Рис. 1. Сеть базовых узлов системы мониторинга ближнего и дальнего космоса.
всего свидетельствует о связи с указанными вебсайтами через геостационарные спутниковые каналы. Большая величина оценки дисперсии для ряда узлов, в том числе для узла, размещенного в САО РАН (п. Н. Архыз), может указывать на возможную систематическую перегрузку или недостаточную пропускную способность канала. Таким образом, на основе данных измерений головной узел — Web-портал следует располагать в Москве.
3. РЕАЛИЗАЦИЯ ДОСТУПА С КЭШИРОВАНИЕМ КОНТЕНТА
Разница в полосе пропускания различных участков Интернет-каналов требует оптимизации их загрузки, поскольку очевидно, что без принятия специальных мер, пропускная способность для транзитного трафика будет соответствовать самому “узкому” участку. При этом следует учитывать и возможную существенную асимметрию трафика для конечных базовых узлов. Типичное различие в загрузке канала при передаче данных к узлу (Down-Stream) и от узла (Up-Stream) составляет более 3-х раз. Так, для САО РАН (п. Н. Архыз) это отношение составляет 4.5 при усреднении за 2005—2006 годы. В университетах с интенсивным “студенческим” трафиком отношение Down/Up-Stream может быть существенно выше. Таким образом, при насыщенном DownStream-трафике основная проблема доступа состоит в том, что многочисленные запросы со
стороны Интернет-пользователей претерпевают существенную задержку на пути к Web-серверу узла по загруженному каналу, ответ же придёт быстро, поскольку обратный канал при этом практически свободен. Решить проблему можно с помощью перенаправления HTTP-запросов на промежуточный кэш-сервер, установленный на площадке, имеющей достаточно широкополосный канал с пропускной способностью, превышающей возможный трафик (см. рис. 2). При этом основной поток Интернет-запросов, включая возможные DoS-атаки, будет отсечен от Web-серверов, обслуживающих наблюдения. До последних будут доходить немногочисленные запросы, связанные с обновлением кэшируемого контента.
В качестве программного обеспечения кэширующего сервера хорошо подходит свободнораспро-страняемый пакет Squid, настроенный как Web-сервер-акселератор. При этом в качестве ускоряемого указывается интернет-адрес Web-сервера базового узла. Перенаправить поток пользовательских запросов из Интернета можно с помощью соответствующих настроек маршрутизатора, например серии Cisco, поддерживающего протокол WCCP [7].
Если перенаправление запросов в маршрутизаторе по различным причинам организовать сложно, то практически того же результата можно добиться, потратив некоторые усилия на модификацию сайта базового узла. Для этого можно ис-
Таблица 1. Web-доступ к базовым узлам
САО РАН, НИВЦМГУ, КЧГТУ, Обсерватория С ГУ, НИИ ПММ ТГУ
Точка измерения Н.Архыз, Москва, Черкесск, Ставрополь, Томск
в Интернет www.sao.ru wO.sao.ru kit.kchr.ru dpts.stavsu.ru solar.tsu.ru
Cреднее время соединения; выборочная а (мс)
Нидерланды: Амстердам, 157; 90 52; 4 85; 8 99; 2 125; 36
Амстердам-1 159; 95 52; 5 89; 26 106; 3 125; 45
Швеция: Стокгольм 170; 100 30; 4 93; 9 142; 8 141; 44
Англия: Лондон 168; 87 61; 6 96; 10 91; 3 136; 34
Германия: Нюрнберг, 167; 77 63; 5 98; 8 185; 11 136; 50
Колонья, 182; 91 54; 5 106; 9 115; 5 157; 95
Мюнхен 186; 187 65; 5 105; 17 125; 2 154; 190
Франция: Париж 188; 113 64; 4 106; 10 106; 2 151; 46
Италия: Кальяри 233; 109 98; 11 155; 16 154; 7 204; 67
Польша: Краков 223; 132 76; 7 140; 21 133; 4 179; 27
Испания: Мадрид 213; 88 104; 5 141; 10 134; 3 194; 158
США: Нью-Йорк, 256; 92 142; 4 184; 9 165; 2 227; 34
Остин, 295, 101 188; 13 217; 16 210; 11 254; 75
Санта Клара 324; 94 197; 4 249; 9 237; 3 298; 137
Канада: Ванкувер 311; 79 215; 9 244; 25 236; 10 300; 159
Китай: Гонконг 443; 97 392; 26 369; 54 380; 13 404; 36
Сингапур: Сингапур 475; 131 392; 10 395; 39 453; 23 503; 84
Австралия: Сидней 479; 111 355; 5 394; 28 396; 3 441; 56
пользовать набор логических правил, предоставляемых программисту средствами специального программного модуля mod_rewrite [8] для Apache HTTP Server (httpd) версий, начиная с 1.3.
Например, основная часть правил существующего набора для корневого Web-сервера САО РАН выглядит следующим образом:
RewriteCond %{HTTP_HOST} 'www\.sao\.ru [ЖС] RewriteRule /і..*) http : //w0.sao.ru/$1 [L, R].
После первого же обращения к серверу www.sao.ru его httpd переопределяет в возвращаемых параметрах стандартного идентификатора ресурса (URI), предназначенного для клиентского браузера, новый адрес перехода на w0.sao.ru. Последний, в свою очередь, принадлежит кэши-
рующему серверу1). Все последующие запросы клиента будут автоматически перенаправляться на получение кэшируемого контента с сервера w0.sao.ru. Разделение локальных и глобальных обращений позволяет освободить Интернет-канал от загрузки потоком обращений к кэширующему серверу от клиентов, находящихся в той же локальной сети, что и базовый узел. Такое разделение можно осуществить с помощью совмещения и разделения по IP-адресам записей для WEB-сервера и кэширующего сервера, соответственно на локальном (внутреннем) и глобальном (внешнем) серверах имен (DNS). При этом запросы локальных пользователей будут автоматически попадать на локальный сервер независимо от его имени, видимого в браузере, поскольку локальный
1)Только для клиентов, определяемых правилами работы mod rewrite и DNS как глобальные.
Г і
, Base-Node і
Рис. 2. Схема кэшированного Web-доступа к базовому узлу.
Рис. 3. Результаты внедрения в конце января 2007 г. кэшированного доступа к Web-серверу САО РАН. Слева выделено: светлым — число страниц, черным — файлов, серым — обращений; вверху справа в те же месяцы: светлым — число клиентских визитов, тёмным — сайтов; внизу справа — измение общего трафика.
DNS будет выдавать один и тот же физический IP-адрес.
Усложнив логику работы модуля mod_rewrite анализом IP-адресов клиентских запросов, можно в некоторых случаях отказаться от переопределения URI для выделенных хостов или целых сетей, что также позволит оптимизировать загрузку сервера и каналов связи. Современные версии модуля позволяют это сделать, для чего следует руководствоваться соответствующим описанием [8].
Необходимые требования по структуре сайта базового узла:
1. HTML-контент базового узла по возможности должен содержать только относительные ссылки, ссылки на CGI-приложения также не
должны быть абсолютными. Следует помнить, что хотя обращения и идут через кэширующий сервер, место выполнения CGI-приложений остается на том сервере, где есть реальный доступ к базам данных или к динамическим данным. Установка же абсолютных ссылок вызовет увеличение количества запросов в обход кэш-сервера и их последующих перенаправлений, что может существенно замедлить взаимодействие между базовыми узлами или выдачей информации клиенту.
2. Сайт должен строиться с минимизацией динамических обращений. Не следует злоупотреблять директивами nocache или малыми значениями refresh в заголовках html-документов там, где это не очень важно.
3. Система поддержки доменного имени сайта должна позволять разделение локального и глобального адресных пространств и допускать переопределение Ф-адресов для выделенных имен WEB-серверов.
В любом случае затраты будут оправданы не только существенным улучшением реактивности системы, но и повышением общей надежности, благодаря в том числе средствам разграничения доступа к веб-сервисам.
4. РЕЗУЛЬТАТЫ ПРОБНОЙ ЭКСПЛУАТАЦИИ КЭШИРУЕМОГО ДОСТУПА
Кэш-сервер w0.sao.ru, размещенный в НИВЦ МГУ, был задействован в конце января 2007 года. Он связан с Web-сервером САО РАН www.sao.ru по имеющемуся 1.5-мегабитному Интернет-каналу Москва—Ростов—Черкесск—Н. Архыз. На рис. 3 отображены результаты помесячного анализа доступа к www.sao.ru в конце 2006 и начале 2007 гг. Политика доступа к нему исключала кэширование запросов только пользователей САО РАН, ЮФУ (Государственный университет Южного федерального округа, Ростов на Дону) и ESO (Южная обсерватория ЕС, для которой обнаружились проблемы с маршрутизацией к сетям МГУ). Запросы из других регионов, в том числе из-за рубежа, при обращении к www.sao.ru перенаправлялись на сервер в Москву. Диаграмма показывает, что число визитов (рис. 3 — справа вверху) на сервер САО РАН за весь период измерений практически не изменялось, а трафик после внедрения кэширования был уплотнен почти в два раза как по числу передаваемых файлов, так и по их объему (рис. 3, соответственно слева и справа внизу). При этом суммарный размер кэшируемых файлов на сервере w0.sao.ru уже к марту 2007 года достиг величины 4.7 Гбайт, а к концу мая — 8 Гбайт, что соизмеримо с текущим объёмом статического контента всего сайта САО РАН. Более детальный анализ статистики обращений к серверу www.sao.ru показал
также сглаживание типовых пиков загрузки сайта запросами от роботов поисковых систем, переместившимися соответственно на w0.sao.ru. Таким образом, удастся избежать дополнительных сложностей во время ночных наблюдений, проводимых на инструментах САО РАН, в том числе удалённо через Интернет-доступ.
БЛАГОДАРНОСТИ
Работа проводится при поддержке Российского фонда фундаментальных исследований, гранты:
№ 06-07-89211-а, № 07-07-00211-а. Авторы благодарны Воеводину В.В. за предоставление вычислительных средств и Пляскиной Т.А. за помощь при внедрении результатов работы в НИВЦ МГУ и САО РАН.
СПИСОК ЛИТЕРАТУРЫ
1. В. В. Витковский, А. А. Иванов, О. П. Желенкова и др. Научный сервис в сети Интернет: Технологии параллельного программирования, Новороссийск (Издательство Московского университета, 2006), с. 245.
2. В. Н. Черненков, Препринт No.113T (Нижний Архыз, САО РАН, 21, 1996).
3. В. Н. Черненков, В. В. Витковский, О. П. Желенкова и др. Математика, компьютер, образование (Москва, 2001), 8, ч.1, c. 156.
4. V Vitkovskij, V Chernenkov, A. Ivanov et al., Baltic Astronomy 9, 527 (2000).
5. С. В. Малхасян, В. В. Витковский, О. П. Желенко-ва и др. Математика, компьютер, образование (Москва, 2001), 8, ч.1, c. 164.
6. WatchMouse — Web site monitoring and uptime statistics http://www.watchmouse.com/
7. В. Н. Черненков, В. В. Витковский, О. П. Желенко-ва и др. Математика, компьютер, образование (Москва, 2001), 8, ч.1, c. 160.
8. Module mod_rewrite — URL Rewriting
Engine http://httpd.apache.org/docs/r3/mod-
/mod_rewrite.html
INTERNET ACCESS TO THE WEB RESOURCES OF A GEOGRAPHICALLY DISTRIBUTED SYSTEM OF NEAR- AND DEEP-SPACE MONITORING
V. N. Chernenkov, V. V. Vitkovskij, N. A. Kalinina
The state and speed characteristics of Web access to the first five nodes of the projected geographically distributed system of scientific monitoring of near and deep space are analyzed. The possibility of developing an architecture involving user query redirection to a caching server is studied. This will make it possible to relieve hardware communication links substantially and speed up HTTP connection time, especially for nodes linked via heavily congested Internet links.
