4. Практическая часть.

Язык HTML . История развития.

Основой даже самых продвинутых Интернет - технологий в настоящий момент является уже давно используемый и все же самый дискутируемый язык HTML. Язык HTML предназначен для разметки и оформления документов в Интернете. Зарождение HTML следует отнести к далекому 1986 году, когда впервые усилиями Международной организации по стандартизации (ISO) был принят ISO-8879-стандарт, названный ими "Standard Generalized Markup Language" (SGML). Данный язык тогда описывался как язык для структурной (логической) разметки текста и не подразумевал наличия хоть сколько-нибудь малого описания внешнего вида документа. Так, задать описание кегля и размера шрифта в SGML считалось противоречащим стандартам того времени, т.к. не обеспечивало кросс - браузерности и кросс - платформенности представленного в таком виде документа. А ведь основной целью создания каких - либо стандартов было достижение именно этого.Однако нужно заметить, SGML не был готовой системой для разметки текста и не предполагал наличия того или иного списка структурных элементов языка, которые должны применяться в определенных обстоятельствах. Этот язык только подразумевал описание синтаксиса написания основных элементов разметки текста, которые в последующем были названы "тэгами". Для практической же разметки документов нужно было создать язык, который описывал бы в каких случаях и какой именно элемент языка необходимо применить и который давал перечень элементов языка, которые могут быть использованы для создания документа и которые должны читаться программами, работающими с этими документами. Язык SGML не получил сколько-нибудь значимого распространения, собственно как и его приложения. Впервые о данном языке вспомнили в глобальных масштабах 1991 году, когда Европейский институт физики частиц ощутил потребность в механизме передачи гипертекстовой информации через Интернет. Тогда они выбрали в качестве основы SGML, и на его базе был создан язык. Вряд ли сейчас кто-либо не знает его названия. HTML (Hyper Text Markup Language, "язык разметки гипертекста").

HTML версии 1.2 содержал около 40 тэгов и не подразумевал какого-либо описания физического представления документов. Все было приведено к логической и структурной разметке текста. Только несколько тэгов (кстати, не рекомендованных для использования) издали намекали на физические свойства представления страниц. В описании одного из этих тэгов было сказано: "При просмотре документа, созданного с использованием данного тэга текст может отображаться в графических браузерах полужирным курсивом".

В 1994 году был создан консорциум W3 (Ц3С), который унаследовал право главенствовать в мире Интернета от Европейского института физики частиц. Эта организация сразу же принялась за создание следующей спецификации HTML версии 2.0. но окончательный стандарт HTML 2.0 был принят только в 1995 году, когда уже полным ходом шло обсуждение и разработка HTML 3.0. Единственным существенным усовершенствованием HTML 2.0 было введение в язык форм - средств отправки информации от пользователя на сервер. Пожалуй, HTML версии 3.0 - самый большой прорыв в HTML-технологиях. Первоначальный вариант стандарта включал в себя много интересных нововведений - теги для создания таблиц, разметки математических формул, вставки обтекаемых текстом рисунков, примечаний и др. Но уже тогда в 1995 году появилась потребность в визуальном оформлении гипертекстовых страниц. Не нарушая основ HTML W3C решили создать отдельную систему для возможности описания визуального оформления HTML-документов. Так появились иерархические стилевые спецификации (Cascading Style Sheets, CSS), имеющие совершенно другую структуру, синтаксис и задачи. О нем будет сказано в следующей статье более подробно.

Вскоре (1995 год) появился первый коммерческий браузер Netscape Navigator, который привел к самому быстрому в истории человечества развитию корпорации Netscape Communications. Дабы привлечь еще и еще клиентов, которых было и так хоть отбавляй, корпорации начала вводить в HTML все новые и новые усовершенствования, которые не были отражены в стандартах W3C и поддерживались только Netscape Navigator. Вводимые все снова и снова тэги были ориентированы на улучшение внешнего вида документов и полностью нарушали изначальные принципы языка.

В 1996 году Microsoft перестал быть пассивным наблюдателем на рынке браузеров, в результате чего появился сначала Microsoft Internet Explorer 2.0, который, нужно сказать, не имел большой популярности. Позднее была создана 3-я версия этого браузера, что поделило рынок браузеров пополам между Navigator Communications и Microsoft. Microsoft взял под свою опеку W3C. В сжатые сроки был создан стандарт HTML версии 3.2, который был полностью ориентирован на Microsoft Internet Explorer.

HTML 3.2 до недавнего времени оставался единственным стандартом этого развивающегося языка WEB-строительства. Эта версия HTML навела относительный порядок в плане поддержки элементов разметки всеми браузерами.

В последние годы (2004 год) была принята последняя на настоящий момент версия HTML - HTML 4.01. Она также обеспечивает достаточно высокую кросс - браузерность и кросс - платформенность.

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

Видимо история HTML, полная борьбы и противоречий, по-видимому, близится к завершению. Точнее, близится к завершению история его развития, так как применяться в более или менее неизменном (и, по-видимому, близком к современному) виде он будет еще долго. В мире накоплено огромное количество ресурсов, жестко привязанных к этому языку, - а, кроме того, при всех его недостатках он сносно справляется с важнейшими из своих обязанностей. Основными же точками роста сейчас становятся другие Internet-технологии, к HTML имеющие довольно опосредованное отношение: Java, ActiveX, VRML, а в последнее время - разномастные push-технологии, которые позволят поставщикам "проталкивать" свою информацию на компьютеры пользователей на манер теле- или радиовещания.

14 html. гиперссылки, вставка картинок

Здравствуйте уважаемые читатели блога KtoNaNovenkogo.ru. В этой очередной статье из рубрики «HTML для чайников» мы продолжим рассматривать html теги. Раннее мы узнали что такое язык Html и тэги по версии валидатора W3C, поговорили об оформлении комментариев в Html и Doctype, а так же затронули тему символов пробела в Html коде и спецсимволов (мнемоник). Да, еще мы обсудили возможности задания цвета в Html.

Сегодня я хочу подробнее остановится на тех html тегах и их атрибутах, с которыми вы будете чаще всего сталкиваться в работе над своим веб-проектом. Это html тег изображений (картинок) Img и html тег ссылки A. Без знания html тегов, позволяющих вставить картинку или ссылку в HTML документ (вебстраницу), очень трудно будет продуктивно работать над дизайном сайта. Эти теги картинок и ссылок активно используются как при написании и оформлении статей, так и в оформлении шаблона, используемого на сайте.

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

Если вы будете знать, как устроены теги и атрибуты, позволяющие вставлять в HTML документ картинки и ссылки, то это может сильно упростить вам жизнь и сэкономить время. Тем более, что изучить десяток самых распространенных тегов и их атрибутов не составит труда. Реально используемых при современной блочной верстке (Html Div) тегов осталось не так уж и много, ну и конечно же, теги вставки ссылок и картинок, являются одними из самых распространенных и часто используемых.

С другой стороны, в оформлении используемого вами шаблона также активно применяются те же самые основные html теги — вставки ссылок, картинок, контейнеры, списки (UL, OL, LI, DL), различные формы html (Form, Input, Button, Checked, Value) и таблицы (Tr, Th, Td, Table). И следовательно, для того, что бы понимать структуру шаблона (шаблоны Joomla, темы WordPress) и при необходимости вносить в него изменения, опять же необходимо знание хотя бы небольшого количества html тегов и атрибутов. Поверьте, потраченное на это время с лихвой окупится в дальнейшем. Ну, будем считать, что я вас убедил в необходимости знакомства с языком html и пора переходить непосредственно к самим html тегам.

Как вставить картинку — html теги Img

Все объявления

ЯндексДирект

Для вставки картинок на страницу служит html тег Img. Представленная ниже картинка вставлена с помощью следующего кода тега Img:

Атрибут Src html тега Img позволяет указать имя и место хранения файла изображения. При этом может быть указана относительная или абсолютная ссылка на файл с картинкой. Пути задаются с помощью символа '/', который служит разделителем между названиями папок, в которых хранятся файлы рисунков.

Абсолютный путь в html теге Img будет начинаться с http://vash_sait.ru (для моего блога — http://ktonanovenkogo.ru). Дальше, используя '/' для разделения имен папок, прописывается полный путь до файла картинки, заканчиваясь в конце именем и расширением самого файла картинки. Например,http://ktonanovenkogo.ru/image/finik.jpg

Относительный путь в html теге Img задается с помощью определения относительного пути от исходной папки, в которой лежит файл самого HTML документа, из которой вы пытаетесь открыть изображение, до файла картинки. Если файл картинки находится на сервере в той же папке, что и HTML документ, из которого к нему обращаются, то путь к нему указывать не нужно — требуется указать только имя файла с картинкой (сохраняя регистр букв).

Если файл изображения находится на том же сервере, но в другом каталоге, требуется указать путь к файлу от каталога, где находится HTML документ, из которого к нему обращаются (в примере, показанном выше, используется как раз относительный путь до файла картинки — image/finik.jpg).

Html тег Img — задаем ширину и высоту изображения с помощью атрибутов Width и Height для ускорения загрузки сайта

Html атрибуты Width и Height позволяют задать размер области (ширину и высоту соответственно), которая будет отводиться на странице под данное изображение. Эти атрибуты вставляются внутри тега Img, например, так:

Если эта область будет не соответствовать реальному размеру картинки, которую вы хотите вставить, то рисунок будет соответственно растянут или сужен, до заданного в html теге Img размера. Тем не менее, не следует использовать это способ, скажем, для уменьшения размера вставляемого в Html документ рисунка. Ведь вес рисунка по-прежнему останется большой, а это будет замедлять загрузку страницы с этим рисунком.

Лучше предварительно изменить размер картинки в графическом редакторе, а уже затем вставлять картинки в Html документ через любой удобный вам Html редактор. Также, при сохранении рисунка в графическом редакторе следует обращать внимание на итоговый вес рисунка. Он не должен быть слишком большой. Иногда лучше немного пожертвовать качеством изображения (благо, что при небольших размерах картинки это будет практически не заметно в Html документе) для уменьшения итогового веса графического файла.

Используйте при сохранении рисунков компактные форматы типа GIF (для вставки схематических картинок) или JPG (для вставки фотографий). Html атрибуты Width и Height, в отличии от атрибута Srс (единственный обязательный атрибут тега Img), являются необязательными. Многие их просто не указывают, но они, тем не менее, позволяют незначительно ускорить загрузку документа с изображениями. Т.к. в комментариях появился вопрос от уважаемого Максима о том, как это происходит и с чем это связано, то я поясню.

Дело в том, что если браузер не находит атрибуты Width и Height внутри html тега Img, то ему потребуется время на то, чтобы узнать размер картинки, загрузить само изображение и только после этого продолжить загружать Html документ. В случае же когда вы прописали атрибуты Height и Width для тега Img, браузер автоматически резервирует место под картинку указанных в этих атрибутах размеров и продолжает загружать веб-страницу дальше.

Если изображения, выводимые на данную страницу очень тяжелые и их очень много, то вставка в html тег Img всех этих картинок атрибутов Height и Width позволит пользователям приступить к чтению текста сайта, в то время как изображения еще будут загружаться.

Также, если вы не укажете атрибуты Width и Height внутри html тега Img, то может возникнуть ситуация, когда при маленькой картинке и очень длинном альтернативном тексте (задается атрибутом Alt в теге Img, об этом речь пойдет ниже), до того как загрузится изображение, временно произойдет сдвиг дизайна сайта, т.к. длинный альтернативный текст из атрибута Alt будет занимать столько места, сколько ему понадобится.

В случае же использования атрибутов Width и Height внутри html тега Img, место для выведение альтернативного текста будет ограничено размерами, заданными в атрибутах размера изображения Width и Height. По большей части, именно из-за этого я стараюсь прописывать атрибуты Width и Height в теге Img.

Атрибуты Alt и Title в html теге Img

Все объявления

ЯндексДирект

Очень полезными, с точки зрения внутренней поисковой оптимизации сайта, являются атрибуты Alt и Title для html тега Img. Более подробно об использовании подобранных в Яндексе ключевых слов вы можете прочитать в статье Продвижение и раскрутка сайта самостоятельно или в публикации Как раскрутить сайт. Первый из них задает, так называемый, альтернативный текст для изображения. Этот текст вы сможете увидеть, если отключите показ картинок в вашем браузере. Атрибут Alt для тега Img и предназначен для этого – рассказать поисковым системам о том, что за рисунок здесь должен был бы быть.Атрибут Title для тега Img предназначен для информирования пользователя о содержании картинки.

Содержимое атрибута Title для тега Img показывается во всплывающей строке, если пользователь подведет мышь к рисунку. Оба этих атрибута для html тега Img (если вы их прописали) позволяют включить изображения вашего веб-проекта впоиск по картинкам Яндекс и Google (а возможно и еще каких-то поисковиков). Поэтому не стоит пренебрегать этой возможность и в обязательном порядке прописывать атрибуты Alt и Title для html тега Img. Оформление ваших изображений должно быть примерно таким:

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

Еще раз напоминаю о правилах написания html тегов. После открывающейся треугольной скобки, обязательно без пробела, пишется название тега, затем, через пробел, пишет название атрибута, допустимого для этого html тега. После названия атрибута, без пробела, ставится знак равно и в кавычках пишется параметр атрибута (например, ширина в пикселях для атрибута Width). Следующий атрибут внутри html тега отделяется от предыдущего атрибута пробелом. В конце html тега ставится закрывающая треугольная скобка. Обращаю ваше внимание, что html тег Img не является парным, т.е. у него нет закрывающего тега.

В идеале, примерно так должны быть оформлены все картинки, используемые на вашем веб-проекте. Такого вида можно добиться и не правя для каждого изображения html код вручную. Визуальные редакторы различных CMS (Joomla, WordPress и др.) позволяют задать атрибуты для html тега Img в удобном для пользователя графическом интерфейсе, но после пробной настройки обязательно проверьте html код (в любом визуальном редакторе можно переключиться на показ html кода статьи). Действительно ли все прописывается именно так, как нужно, потому как не всегда сразу понятно, какое именно поле в визуальном редакторе соответствует тому или иному атрибуту html кода.

Создаем гиперссылки с помощью html тега ссылки A

Ссылка — один из основных элементов организации Html документа. Без них вебстраница была бы просто страницей. Ссылки создаются при помощи html тега ссылки А. Обязательным атрибутом html тега ссылки А является атрибут Href. Он задает URL ресурса, куда должен перейти пользователь, щелкнув по данной гиперссылке.

Ссылка может вести как на внутреннюю страницу вашего же сайта (очень важный момент внутренней оптимизации сайта связан именно с внутренней перелинковкой страниц), так и на страницу другого проекта. Html тег ссылки A является парным и соответственно имеет закрывающий тег. Текст ссылки (анкор)размещается между открывающим и закрывающим html тегами ссылки A. Пример ссылки:

Поисковые системы анализируют не только сам текст ссылки (анкор ссылки), но и слова окружающие ссылку. Это следует учитывать при размещении ссылок на свой сайт (обратных ссылок на сайт) на других ресурсах (постовые, платные ссылки). Для того, чтобы ссылка выглядела более натурально, можно часть текста вынести за пределы ссылки, например:

Target _blank ( в новом окне) для html тега A

Все объявления

ЯндексДирект

Ну, ладно, это мы опять отвлеклись на поисковую оптимизацию. Вернемся снова к тегам. Для html тега ссылки A имеется один очень нужный атрибут, который позволит открывать страницу, на которую ведет данная ссылка в новом окне. Это может понадобиться если вы с одной своей страницы ссылаетесь на множество внешних Html документов. В этом случае посетителю вашего сайта было бы удобнее, чтобы ваша страница оставалась всегда открытой.

Это атрибут html тега ссылки Target, а параметр этого атрибута, позволяющий открывать страницу в новом окне, называется _BLANK. Если атрибут Target не задан в html теге ссылки A, то ссылка будет открываться в этом же окне. Пример использования атрибута Target в теге ссылки A:

Обратите внимание, что порядок следования атрибутов внутри html тегов никак не регламентирован. С таким же успехом можно написать:

Ссылка с картинки (изображения) в html теге A

В качестве анкора для html тега ссылки, вместо текста, может использоватьсяизображение. В этом случае html тег Img заключается в открывающий и закрывающий теги ссылки A:

Есть мнение, что поисковики выше ценят ссылки с картинки, а по некоторым данным выходит обратное. Но при использовании такого типа ссылки нет текста ссылки (анкора), в который можно было бы вставить нужные ключевые слова. В этом случае можно использовать атрибут Title для html тега ссылки A.

Этот атрибут Title можно использовать и в случае использования обычного текстового анкора для Html тега ссылки. В этом случае, информация прописанная в атрибуте Title тега ссылки A будет видна, если подвести курсор мыши к гиперссылке.

Здесь нужно прописать ключевые слова, по которым вы хотите продвинуть статью, на которую ведет эта ссылка

Создание якорей (атрибут NAME) и хеш-ссылок с помощью Html тега ссылки A

Все объявления

ЯндексДирект

Еще один интересный атрибут html тега ссылки NAME, который довольно широко используется для создания так называемых якорей ссылок, на которые потом можно будет ссылаться с помощью так называемых хеш-ссылок. Немного запутанно, но сейчас попробую внести ясность. Допустим, что вам нужно сослаться на конкретное место в тексте, где идет обсуждение определенного вопроса.

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

Для реализации описанного способа создания гиперссылок в Html документе, нужно предварительно вставить якорь html ссылки в ту статью, на которую будет вести хеш-ссылка. Якорь гиперссылки представляет из себя конструкцию напоминающую обычную ссылку, но при этом он остается невидимым для посетителя. Выглядит он так:

Т.е. получается, что якорь состоит только из открывающего и закрывающего тега ссылки А, при этом якорь ссылки не содержит анкора и имеет один единственный обязательный атрибут NAME html тега ссылки A. Параметром этого атрибута будет служить метка, название которой вы задаете сами. Эта метка будет использоваться при создании хеш-ссылки.

Итак, после того, как мы расставили в тексте статьи все необходимые якоря гиперссылок, можно приступать к созданию хеш-ссылок, которые будут ссылаться на места в тексте статьи, заранее помеченные якорями ссылки. Гиперссылка создается стандартным для Html образом, за исключением того, что в конце URL, который прописывается в атрибуте Href, ставится знак решетки (знак диеза или хеш-символ), а после него имя метки того якоря ссылки, который стоит в требуемом месте текста статьи. Хеш-ссылка будет выглядеть примерно так:

Лучший FTP клиент FileZilla

С помощью хеш-ссылки вы перейдете не только на страницу “Как настроить доступ к сайту по FTP с помощью программы FileZilla ”, но также браузер автоматически прокрутит окно до нужного месте в тексте (в данном случае до вопроса о редактировании файлов сайта с помощью FileZilla).

Если якорь ссылки находится в том же Html документе, что и хеш-ссылка, то можно не указывать в гиперссылке URL этой вебстранице, а указать только якорь ссылки.

Пример использования хеш-ссылок вы можете посмотреть в действии на странице FAQ (Вопросы и Ответы) этого блога. Хеш-ссылки c этой вебстраницы ведут на различные места в текстах статей, где обсуждаются те или иные вопросы. Без использования хеш-ссылок создать такую вебстраницу было бы невозможно.

15 html. создание таблиц

Для создания таблицы служит тэг <TABLE>. Как известно таблица состоит из строк, а строки, в свою очередь состоят из ячеек. Для определения строк служит тэг <TR>, для создания ячеек - <TH>, <TD>.

Тэг <TH> используется для создания ячеек с заголовками.

Тэг <TD> - для обыкновенных ячеек с данными.

Содержание ячеек заголовков отображается полужирным шрифтом и выравнивается по центру.

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

Пример:

Обрамление таблицы документа html

Для того, чтобы сделать видимой границы таблицы, служит атрибут BORDER тэга <TABLE>.

Определяя рамку таблицы, надо указать толщину ее внешних линий в пикселях. Чтобы задать толщину разграничивающих линий внутри таблицы, необходимо воспользоваться атрибутом CELLSPACING.

По умолчанию браузер отображает рамку таблицы темно-серым цветом. Чтобы изменить цвет рамки надо применить атрибут BORDERCOLOR.

Пример:

Заголовок таблицы документа html

Для создания заголовка таблицы служит тэг <CAPTION>.

По умолчанию браузер располагает заголовок таблицы по центру над ней. При помощи атрибута ALIGN со значением bottom можно разместить заголовок под таблицей.

Следует сказать, что стандарт HTML не позволяет ставить одной таблице несколько заголовков.

Пример:

Группирование столбцов документа html

Для группирования столбцов таблицы служат тэги <COLGROUP> и <COL>.

Дескриптор <COLGROUP> создает структурную группу столбцов, которая выделяет множество логически однородных ячеек. Так одна структурная группа может охватывать ячейки заголовков столбцов, а другая - ячейки, содержащие данные.

Дескриптор <COL> предназначен для формирования неструктурных групп столбцов, которые делят таблицу на разделы, не имеющих отношения к структуре. Это удобно в том случае, когда не все столбцы содержат информацию одного типа.

Пример:

Группирование строк документа html

Для группирования строк таблицы служат тэги <THEAD>, <TBODY>, <TFOOT>.

<THEAD> - нужен для создания группы заголовков для столбцов таблицы. Этот дескриптор допускается использовать в пределах таблицы только одни раз.

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

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

Пример:

16 MySQL.Установка и настройка серверной части

Пора заняться установкой MySQL-сервера, поскольку много чего будем хранить именно в этой базе данных.

Список необходимых опций сборки добавим в /etc/make.conf:

Приступаем непосредственно к инсталляции серверной части (клиентскую часть подтянет автоматически).

Добавляем в /etc/rc.conf строку о необходимости запуска MySQL-сервера:

Запускаем сервер

Меняем пароль для пользователя root в MySQL (хотя, обычно, завожу пользователя с полными привилегиями, а запись пользователя root удаляю полностью):

Теперь следует отредактировать конфигурационный файл mysql, который называется my.cnf. Положить его можно в любую из этих папок: /var/db/mysql/, /etc/, /usr/local/etc/. MySQL при запуске проверит его наличие во всех этих каталогах. Если конфигурациооный файл отсутствует – можно скопировать доступный пример и при необходимости отредактировать его (доступны примеры для нагруженного сервера, для сервера со средней нагрузкой и для ненагруженного сервера)

Для решения проблем с кодировкой кирилицы, добавим в секцию [client]:

И, соответственно, в секцию [mysqld]:

Также, для удобства, можете изменить параметры логгирования. Для этого в секцию [mysqld] файла /var/db/mysql/my.cnf добавляем строку log=/var/log/mysql.log

Также необходимо создать сам файл логов:

Перегружаем MySQL для того, чтобы новые настройки вступили в силу:

Кстати... Если уж возьметесь писать логи MySQL - ОБЯЗАТЕЛЬНО настройте ротацию логов, а не то лог-файл очень скоро разрастется до неимоверных размеров (вплоть до того, что не останется свободного места на разделе. Например, будем архивировать лог раз в неделю. Для этого в /etc/newsyslog.conf необходимо добавить следующую строку:

Обратите внимание: pid-файл будет уникальный (зависит от от имени сервера).

Дальше создадим пользователя, с правами суперпользователя в БД MySQL:

Теперь еще осталось удалить остальных пользователей, которых mysql создает по-умолчанию.

17 склады данных и система оперативно-аналитической обработки данных

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

В последние годы в мире оформился ряд новых концепций хранения и анализа корпоративных данных:

1) Хранилища данных, или Склады данных (Data Warehouse) [15, 5];

2) Оперативная аналитическая обработка (On-Line Analytical Processing, OLAP) [11, 6, 10];

3) Интеллектуальный анализ данных - ИАД (Data Mining) [17, 19, 23, 3].

Технологии OLAP тесно связаны с технологиями построения Data Warehouse и методами интеллектуальной обработки - Data Mining. Поэтому наилучшим вариантом является комплексный подход к их внедрению.

Способы аналитической обработки данных

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

Очень часто информационно-аналитические системы, создаваемые в расчете на непосредственное использование лицами, принимающими решения, оказываются чрезвычайно просты в применении, но жестко ограничены в функциональности. Такие статические системы называются в литературе Информационными системами руководителя (ИСР), или Executive Information Systems (EIS) [3]. Они содержат в себе предопределенные множества запросов и, будучи достаточными для повседневного обзора, неспособны ответить на все вопросы к имеющимся данным, которые могут возникнуть при принятии решений. Результатом работы такой системы, как правило, являются многостраничные отчеты, после тщательного изучения которых у аналитика появляется новая серия вопросов. Однако каждый новый запрос, непредусмотренный при проектировании такой системы, должен быть сначала формально описан, закодирован программистом и только затем выполнен. Время ожидания в таком случае может составлять часы и дни, что не всегда приемлемо. Таким образом, внешняя простота статических СППР, за которую активно борется большинство заказчиков информационно-аналитических систем, оборачивается катастрофической потерей гибкости.

Динамические СППР, напротив, ориентированы на обработку нерегламентированных (ad hoc) запросов аналитиков к данным. Наиболее глубоко требования к таким системам рассмотрел E. F. Codd в статье [11], положившей начало концепции OLAP. Работа аналитиков с этими системами заключается в интерактивной последовательности формирования запросов и изучения их результатов.

Но динамические СППР могут действовать не только в области оперативной аналитической обработки (OLAP); поддержка принятия управленческих решений на основе накопленных данных может выполняться в трех базовых сферах [21].

1. Сфера детализированных данных. Это область действия большинства систем, нацеленных на поиск информации. В большинстве случаев реляционные СУБД отлично справляются с возникающими здесь задачами. Общепризнанным стандартом языка манипулирования реляционными данными является SQL. Информационно-поисковые системы, обеспечивающие интерфейс конечного пользователя в задачах поиска детализированной информации, могут использоваться в качестве надстроек как над отдельными базами данных транзакционных систем, так и над общим хранилищем данных.

2. Сфера агрегированных показателей. Комплексный взгляд на собранную в хранилище данных информацию, ее обобщение и агрегация, гиперкубическое представление и многомерный анализ являются задачами систем оперативной аналитической обработки данных (OLAP) [11, 10, 6]. Здесь можно или ориентироваться на специальные многомерные СУБД [6], или оставаться в рамках реляционных технологий. Во втором случае заранее агрегированные данные могут собираться в БД звездообразного вида, либо агрегация информации может производиться на лету в процессе сканирования детализированных таблиц реляционной БД.

3. Сфера закономерностей. Интеллектуальная обработка производится методами интеллектуального анализа данных (ИАД, Data Mining) [19, 25], главными задачами которых являются поиск функциональных и логических закономерностей в накопленной информации, построение моделей и правил, которые объясняют найденные аномалии и/или прогнозируют развитие некоторых процессов.

Некоторые авторы [21] выделяют в отдельную область анализ отклонений (например, в целях отслеживания колебаний биржевых курсов). В качестве примера может быть приведен статистический анализ рядов динамики. Чаще, однако, этот тип анализа относят к области закономерностей.

Полная структура информационно-аналитической системы, построенной на основе хранилища данных, показана на рис. 1. В конкретных реализациях отдельные компоненты этой схемы часто отсутствуют.

Рис. 1. Полная структура корпоративной информационно-аналитической системы (ИАС)

Оперативная аналитическая обработка данных

В основе концепции OLAP лежит принцип многомерного представления данных. В 1993 году в статье [11] E. F. Codd рассмотрел недостатки реляционной модели, в первую очередь указав на невозможность "объединять, просматривать и анализировать данные с точки зрения множественности измерений, то есть самым понятным для корпоративных аналитиков способом", и определил общие требования к системам OLAP, расширяющим функциональность реляционных СУБД и включающим многомерный анализ как одну из своих характеристик.

В большом числе публикаций аббревиатурой OLAP обозначается не только многомерный взгляд на данные, но и хранение самих данных в многомерной БД [6]. Вообще говоря, это неверно, поскольку сам Кодд отмечает, что "Реляционные БД были, есть и будут наиболее подходящей технологией для хранения корпоративных данных. Необходимость существует не в новой технологии БД, а, скорее, в средствах анализа, дополняющих функции существующих СУБД и достаточно гибких, чтобы предусмотреть и автоматизировать разные виды интеллектуального анализа, присущие OLAP". Такая путаница приводит к противопоставлениям наподобие "OLAP или ROLAP", что не совсем корректно, поскольку ROLAP (реляционный OLAP) на концептуальном уровне поддерживает всю определенную термином OLAP функциональность. Более предпочтительным кажется использование для OLAP на основе многомерных СУБД специального термина MOLAP, как это и сделано в [4, 9].

По Кодду, многомерное концептуальное представление (multi-dimensional conceptual view) представляет собой множественную перспективу, состоящую из нескольких независимых измерений, вдоль которых могут быть проанализированы определенные совокупности данных. Одновременный анализ по нескольким измерениям определяется как многомерный анализ. Каждое измерение включает направления консолидации данных, состоящие из серии последовательных уровней обобщения, где каждый вышестоящий уровень соответствует большей степени агрегации данных по соответствующему измерению. Так, измерение Исполнитель может определяться направлением консолидации, состоящим из уровней обобщения "предприятие - подразделение - отдел - служащий". Измерение Время может даже включать два направления консолидации - "год - квартал - месяц - день" и "неделя - день", поскольку счет времени по месяцам и по неделям несовместим. В этом случае становится возможным произвольный выбор желаемого уровня детализации информации по каждому из измерений. Операция спуска (drilling down) соответствует движению от высших ступеней консолидации к низшим; напротив, операция подъема (rolling up) означает движение от низших уровней к высшим (рис. 2).

Рис. 2. Измерения и направления консолидации данных

Требования к средствам оперативной аналитической обработки

Кодд определил 12 правил, которым должен удовлетворять программный продукт класса OLAP (табл. 1).

Таблица 1 Правила оценки программных продуктов класса OLAP

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

Классификация продуктов OLAP по способу представления данных

В настоящее время на рынке присутствует большое количество продуктов, которые в той или иной степени обеспечивают функциональность OLAP. Около 30 наиболее известных перечислены в списке обзорного Web-сервера http://www.olapreport.com/. Обеспечивая многомерное концептуальное представление со стороны пользовательского интерфейса к исходной базе данных, все продукты OLAP делятся на три класса по типу исходной БД.

1. Самые первые системы оперативной аналитической обработки (например, Essbase компании Arbor Software [11], Oracle Express Server компании Oracle [6]) относились к классу MOLAP, то есть могли работать только со своими собственными многомерными базами данных. Они основываются на патентованных технологиях для многомерных СУБД и являются наиболее дорогими. Эти системы обеспечивают полный цикл OLAP-обработки. Они либо включают в себя, помимо серверного компонента, собственный интегрированный клиентский интерфейс, либо используют для связи с пользователем внешние программы работы с электронными таблицами. Для обслуживания таких систем требуется специальный штат сотрудников, занимающихся установкой, сопровождением системы, формированием представлений данных для конечных пользователей.

2. Системы оперативной аналитической обработки реляционных данных (ROLAP) позволяют представлять данные, хранимые в реляционной базе, в многомерной форме [13, 14, 22], обеспечивая преобразование информации в многомерную модель через промежуточный слой метаданных. К этому классу относятся DSS Suite компании MicroStrategy, MetaCube компании Informix, DecisionSuite компании Information Advantage и другие. Программный комплекс ИнфоВизор [1], разработанный в России, в Ивановском государственном энергетическом университете, также является системой этого класса. ROLAP-системы хорошо приспособлены для работы с крупными хранилищами. Подобно системам MOLAP, они требуют значительных затрат на обслуживание специалистами по информационным технологиям и предусматривают многопользовательский режим работы.

3. Наконец, гибридные системы (Hybrid OLAP, HOLAP) разработаны с целью совмещения достоинств и минимизации недостатков, присущих предыдущим классам. К этому классу относится Media/MR компании Speedware [9]. По утверждению разработчиков, он объединяет аналитическую гибкость и скорость ответа MOLAP с постоянным доступом к реальным данным, свойственным ROLAP.

Помимо перечисленных средств существует еще один класс - инструменты генерации запросов и отчетов для настольных ПК, дополненные функциями OLAP или интегрированные с внешними средствами, выполняющими такие функции. Эти хорошо развитые системы осуществляют выборку данных из исходных источников, преобразуют их и помещают в динамическую многомерную БД, функционирующую на клиентской станции конечного пользователя. Основными представителями этого класса являются BusinessObjects одноименной компании [18], BrioQuery компании Brio Technology [7] и PowerPlay компании Cognos [7].

Многомерный OLAP (MOLAP)

В специализированных СУБД, основанных на многомерном представлении данных, данные организованы не в форме реляционных таблиц, а в виде упорядоченных многомерных массивов:

1) гиперкубов (все хранимые в БД ячейки должны иметь одинаковую мерность, то есть находиться в максимально полном базисе измерений) или

2) поликубов (каждая переменная хранится с собственным набором измерений, и все связанные с этим сложности обработки перекладываются на внутренние механизмы системы).

Использование многомерных БД в системах оперативной аналитической обработки имеет следующие достоинства.

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

2. Многомерные СУБД легко справляются с задачами включения в информационную модель разнообразных встроенных функций, тогда как объективно существующие ограничения языка SQL делают выполнение этих задач на основе реляционных СУБД достаточно сложным, а иногда и невозможным.

С другой стороны, имеются существенные ограничения.

1. Многомерные СУБД не позволяют работать с большими базами данных. К тому же за счет денормализации и предварительно выполненной агрегации объем данных в многомерной базе, как правило, соответствует (по оценке Кодда [11]) в 2.5-100 раз меньшему объему исходных детализированных данных.

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

Следовательно, использование многомерных СУБД оправдано только при следующих условиях.

1. Объем исходных данных для анализа не слишком велик (не более нескольких гигабайт), то есть уровень агрегации данных достаточно высок.

2. Набор информационных измерений стабилен (поскольку любое изменение в их структуре почти всегда требует полной перестройки гиперкуба).

3. Время ответа системы на нерегламентированные запросы является наиболее критичным параметром.

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

Реляционный OLAP (ROLAP)

Непосредственное использование реляционных БД в системах оперативной аналитической обработки имеет следующие достоинства.

1. В большинстве случаев корпоративные хранилища данных реализуются средствами реляционных СУБД, и инструменты ROLAP позволяют производить анализ непосредственно над ними. При этом размер хранилища не является таким критичным параметром, как в случае MOLAP.

2. В случае переменной размерности задачи, когда изменения в структуру измерений приходится вносить достаточно часто, ROLAP системы с динамическим представлением размерности являются оптимальным решением, так как в них такие модификации не требуют физической реорганизации БД.

3. Реляционные СУБД обеспечивают значительно более высокий уровень защиты данных и хорошие возможности разграничения прав доступа.

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

Описанию схемы звезды (star schema) и рекомендациям по ее применению полностью посвящены работы [14, 22, 16]. Ее идея заключается в том, что имеются таблицы для каждого измерения, а все факты помещаются в одну таблицу, индексируемую множественным ключом, составленным из ключей отдельных измерений (рис. 3). Каждый луч схемы звезды задает, в терминологии Кодда, направление консолидации данных по соответствующему измерению.

Рис. 3. Пример схемы "звезды"

В сложных задачах с многоуровневыми измерениями имеет смысл обратиться к расширениям схемы звезды - схеме созвездия (fact constellation schema) и схеме снежинки (snowflake schema) [22]. В этих случаях отдельные таблицы фактов создаются для возможных сочетаний уровней обобщения различных измерений (рис. 4). Это позволяет добиться лучшей производительности, но часто приводит к избыточности данных и к значительным усложнениям в структуре базы данных, в которой оказывается огромное количество таблиц фактов.

Рис. 4. Пример схемы "снежинки" (фрагмент для одного измерения)

Увеличение числа таблиц фактов в базе данных может проистекать не только из множественности уровней различных измерений, но и из того обстоятельства, что в общем случае факты имеют разные множества измерений. При абстрагировании от отдельных измерений пользователь должен получать проекцию максимально полного гиперкуба, причем далеко не всегда значения показателей в ней должны являться результатом элементарного суммирования. Таким образом, при большом числе независимых измерений необходимо поддерживать множество таблиц фактов, соответствующих каждому возможному сочетанию выбранных в запросе измерений, что также приводит к неэкономному использованию внешней памяти, увеличению времени загрузки данных в БД схемы звезды из внешних источников и сложностям администрирования. Частично решают эту проблему расширения языка SQL (операторы "GROUP BY CUBE", "GROUP BY ROLLUP" и "GROUP BY GROUPING SETS"); кроме того, авторы статей [14, 16] предлагают механизм поиска компромисса между избыточностью и быстродействием, рекомендуя создавать таблицы фактов не для всех возможных сочетаний измерений, а только для тех, значения ячеек которых не могут быть получены с помощью последующей агрегации более полных таблиц фактов (рис. 5).

Рис. 5. Таблицы фактов для разных сочетаний измерений в запросе

В любом случае, если многомерная модель реализуется в виде реляционной базы данных, следует создавать длинные и "узкие" таблицы фактов и сравнительно небольшие и "широкие" таблицы измерений. Таблицы фактов содержат численные значения ячеек гиперкуба, а остальные таблицы определяют содержащий их многомерный базис измерений. Часть информации можно получать с помощью динамической агрегации данных, распределенных по незвездообразным нормализованным структурам, хотя при этом следует помнить, что включающие агрегацию запросы при высоконормализованной структуре БД могут выполняться довольно медленно.

Ориентация на представление многомерной информации с помощью звездообразных реляционных моделей позволяет избавиться от проблемы оптимизации хранения разреженных матриц, остро стоящей перед многомерными СУБД (где проблема разреженности решается специальным выбором схемы). Хотя для хранения каждой ячейки используется целая запись, которая помимо самих значений включает вторичные ключи - ссылки на таблицы измерений, несуществующие значения просто не включаются в таблицу фактов.

Интеллектуальный анализ данных

ИАД (Data Mining) - это процесс поддержки принятия решений, основанный на поиске в данных скрытых закономерностей (шаблонов информации). При этом накопленные сведения автоматически обобщаются до информации, которая может быть охарактеризована как знания.

В общем случае процесс ИАД состоит из трёх стадий [19] (рис. 6):

1) выявление закономерностей (свободный поиск);

2) использование выявленных закономерностей для предсказания неизвестных значений (прогностическое моделирование);

3) анализ исключений, предназначенный для выявления и толкования аномалий в найденных закономерностях.

Иногда в явном виде выделяют промежуточную стадию проверки достоверности найденных закономерностей между их нахождением и использованием (стадия валидации).

Рис. 6. Стадии процесса интеллектуального анализа данных

Все методы ИАД подразделяются на две большие группы по принципу работы с исходными обучающими данными [19].

1. В первом случае исходные данные могут храниться в явном детализированном виде и непосредственно использоваться для прогностического моделирования и/или анализа исключений; это так называемые методы рассуждений на основе анализа прецедентов. Главной проблемой этой группы методов является затрудненность их использования на больших объемах данных, хотя именно при анализе больших хранилищ данных методы ИАД приносят наибольшую пользу.

2. Во втором случае информация вначале извлекается из первичных данных и преобразуется в некоторые формальные конструкции (их вид зависит от конкретного метода). Согласно предыдущей классификации, этот этап выполняется на стадии свободного поиска, которая у методов первой группы в принципе отсутствует. Таким образом, для прогностического моделирования и анализа исключений используются результаты этой стадии, которые гораздо более компактны, чем сами массивы исходных данных. При этом полученные конструкции могут быть либо "прозрачными" (интерпретируемыми), либо "черными ящиками" (нетрактуемыми).

Две эти группы и примеры входящих в них методов представлены на рис. 7.

Рис. 7. Классификация технологических методов ИАД

Интеграция OLAP и ИАД

Оперативная аналитическая обработка и интеллектуальный анализ данных - две составные части процесса поддержки принятия решений. Но сегодня большинство систем OLAP заостряет внимание только на обеспечении доступа к многомерным данным, а большинство средств ИАД, работающих в сфере закономерностей, имеют дело с одномерными перспективами данных. Эти два вида анализа должны быть тесно объединены, то есть системы OLAP должны фокусироваться не только на доступе, но и на поиске закономерностей. Как заметил N. Raden, "многие компании создали ... прекрасные хранилища данных, идеально разложив по полочкам горы неиспользуемой информации, которая сама по себе не обеспечивает ни быстрой, ни достаточно грамотной реакции на рыночные события".

K. Parsaye [20] вводит составной термин "OLAP Data Mining" (многомерный интеллектуальный анализ) для обозначения такого объединения (рис. 8). J. Han [65] предлагает еще более простое название - "OLAP Mining", и предлагает несколько вариантов интеграции двух технологий.

1. "Cubing then mining". Возможность выполнения интеллектуального анализа должна обеспечиваться над любым результатом запроса к многомерному концептуальному представлению, то есть над любым фрагментом любой проекции гиперкуба показателей.

2. "Mining then cubing". Подобно данным, извлечённым из хранилища, результаты интеллектуального анализа должны представляться в гиперкубической форме для последующего многомерного анализа.

3. "Cubing while mining". Этот гибкий способ интеграции позволяет автоматически активизировать однотипные механизмы интеллектуальной обработки над результатом каждого шага многомерного анализа (перехода между уровнями обобщения, извлечения нового фрагмента гиперкуба и т. д.).

К сожалению, очень немногие производители предоставляют сегодня достаточно мощные средства интеллектуального анализа многомерных данных в рамках систем OLAP. Проблема также заключается в том, что некоторые методы ИАД (байесовские сети, метод k-ближайшего соседа) неприменимы для задач многомерного интеллектуального анализа, так как основаны на определении сходства детализированных примеров и не способны работать с агрегированными данными [20].

Рис. 8. Архитектура системы многомерного интеллектуального анализа данных

Критерии оценки существующих продуктов

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

1. Удобство и богатство возможностей средств администрирования. Работа администратора является самой важной и самой сложной частью эксплуатации OLAP-системы. Поэтому следует обращать внимание на удобство интерфейса администрирования, а более того - на спектр его функциональных возможностей. Как формируются новые измерения? Как модифицируется существующая модель? Требуется ли создание базы данных жестко заданной структуры, или можно анализировать данные, собранные в ранее созданных базах (в случае ROLAP)? На все эти вопросы необходимо получить ясный и четкий ответ.

2. Гибкость настройки и наглядность форм демонстрации результатов. Интуитивность представления информации - главная изюминка OLAP. Насколько качественно и удобно формируются отчёты? Наглядны ли графические возможности, существует ли связь с ГИС-технологиями? Налажены ли механизмы экспорта результатов в стандартные форматы?

3. Спектр методов постобработки данных, доступность средств интеллектуального анализа. Богаты ли аналитические возможности инструмента? Есть ли в нём элементы Data Mining, и если есть, какие преимущества они могут обеспечить при использовании?

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

5. Возможность увязки OLAP-инструментария со всеми СУБД, используемыми в организации. Как показывает практика, интеграция разнородных продуктов в устойчиво работающую систему - один из наиболее важных вопросов, и его решение в ряде случаев может быть связано с большими проблемами. Необходимо разобраться, насколько просто и надёжно можно интегрировать средства OLAP с существующими в организации СУБД.

Кроме того, разумеется, одним из ключевых критериев выбора программных продуктов является цена. А продукты OLAP существенно отличаются друг от друга по этому показателю.

18,19 вызов удаленных процедур

Идея вызова удаленных процедур (Remote Procedure Call - RPC) состоит в расширении хорошо известного и понятного механизма передачи управления и данных внутри программы, выполняющейся на одной машине, на передачу управления и данных через сеть. Средства удаленного вызова процедур предназначены для облегчения организации распределенных вычислений. Наибольшая эффективность использования RPC достигается в тех приложениях, в которых существует интерактивная связь между удаленными компонентами с небольшим временем ответов и относительно малым количеством передаваемых данных. Такие приложения называются RPC-ориентированными.

Характерными чертами вызова локальных процедур являются:

• Асимметричность, то есть одна из взаимодействующих сторон является инициатором;

• Синхронность, то есть выполнение вызывающей процедуры при останавливается с момента выдачи запроса и возобновляется только после возврата из вызываемой процедуры.

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

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

Эти и некоторые другие проблемы решает широко распространенная технология RPC, лежащая в основе многих распределенных операционных систем.

Базовые операции RPC

Чтобы понять работу RPC, рассмотрим вначале выполнение вызова локальной процедуры в обычной машине, работающей автономно. Пусть это, например, будет системный вызов

count=read (fd,buf,nbytes);

где fd - целое число,  buf - массив символов,  nbytes - целое число.

Чтобы осуществить вызов, вызывающая процедура заталкивает параметры в стек в обратном порядке (рисунок 3.1). После того, как вызов read выполнен, он помещает возвращаемое значение в регистр, перемещает адрес возврата и возвращает управление вызывающей процедуре, которая выбирает параметры из стека, возвращая его в исходное состояние. Заметим, что в языке С параметры могут вызываться или по ссылке (by name), или по значению (by value). По отношению к вызываемой процедуре параметры-значения являются инициализируемыми локальными переменными. Вызываемая процедура может изменить их, и это не повлияет на значение оригиналов этих переменных в вызывающей процедуре.

Если в вызываемую процедуру передается указатель на переменную, то изменение значения этой переменной вызываемой процедурой влечет изменение значения этой переменной и для вызывающей процедуры. Этот факт весьма существенен для RPC.

Существует также другой механизм передачи параметров, который не используется в языке С. Он называется call-by-copy/restore и состоит в необходимости копирования вызывающей программой переменных в стек в виде значений, а затем копирования назад после выполнения вызова поверх оригинальных значений вызывающей процедуры.

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

Рис. 3.1. а) Стек до выполнения вызова read;  б) Стек во время выполнения процедуры;  в) Стек после возврата в вызывающую программу

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

RPC достигает прозрачности следующим путем. Когда вызываемая процедура действительно является удаленной, в библиотеку помещается вместо локальной процедуры другая версия процедуры, называемая клиентским стабом (stub - заглушка). Подобно оригинальной процедуре, стаб вызывается с использованием вызывающей последовательности (как на рисунке 3.1), так же происходит прерывание при обращении к ядру. Только в отличие от оригинальной процедуры он не помещает параметры в регистры и не запрашивает у ядра данные, вместо этого он формирует сообщение для отправки ядру удаленной машины.

Этапы выполнения RPC

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

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

Рис. 3.2. Remote Procedure Call

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

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

Теперь начинает работу серверный стаб. Он распаковывает параметры и помещает их соответствующим образом в стек. Когда все готово, выполняется вызов сервера. После выполнения процедуры сервер передает результаты клиенту. Для этого выполняются все описанные выше этапы, только в обратном порядке.

Рисунок 3.3 показывает последовательность команд, которую необходимо выполнить для каждого RPC-вызова, а рисунок 3.4 - какая доля общего времени выполнения RPC тратится на выполнение каждого их описанных 14 этапов. Исследования были проведены на мультипроцессорной рабочей станции DEC Firefly, и, хотя наличие пяти процессоров обязательно повлияло на результаты измерений, приведенная на рисунке гистограмма дает общее представление о процессе выполнения RPC.

Рис. 3.3. Этапы выполнения процедуры RPC

Рис. 3.4. Распределение времени между 14 этапами выполнения RPC

1. Вызов стаба

2. Подготовить буфер

3. Упаковать параметры

4. Заполнить поле заголовка

5. Вычислить контрольную сумму в сообщении

6. Прерывание к ядру

7. Очередь пакета на выполнение

8. Передача сообщения контроллеру по шине QBUS

9. Время передачи по сети Ethernet

10. Получить пакет от контроллера

11. Процедура обработки прерывания

12. Вычисление контрольной суммы

13. Переключение контекста в пространство пользователя

14. Выполнение серверного стаба

Динамическое связывание

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

Начальным моментом для динамического связывания является формальное определение (спецификация) сервера. Спецификация содержит имя файл-сервера, номер версии и список процедур-услуг, предоставляемых данным сервером для клиентов (рисунок 3.5). Для каждой процедуры дается описание ее параметров с указанием того, является ли данный параметр входным или выходным относительно сервера. Некоторые параметры могут быть одновременно входными и выходными - например, некоторый массив, который посылается клиентом на сервер, модифицируется там, а затем возвращается обратно клиенту (операция copy/ restore).

Рис. 3.5. Спецификация сервера RPC

Формальная спецификация сервера используется в качестве исходных данных для программы-генератора стабов, которая создает как клиентские, так и серверные стабы. Затем они помещаются в соответствующие библиотеки. Когда пользовательская (клиентская) программа вызывает любую процедуру, определенную в спецификации сервера, соответствующая стаб-процедура связывается с двоичным кодом программы. Аналогично, когда компилируется сервер, с ним связываются серверные стабы.

При запуске сервера самым первым его действием является передача своего серверного интерфейса специальной программе, называемой binder'ом. Этот процесс, известный как процесс регистрации сервера, включает передачу сервером своего имени, номера версии, уникального идентификатора и описателя местонахождения сервера. Описатель системно независим и может представлять собой IP, Ethernet, X.500 или еще какой-либо адрес. Кроме того, он может содержать и другую информацию, например, относящуюся к аутентификации.

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

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

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

Однако у динамического связывания имеются недостатки, например, дополнительные накладные расходы (временные затраты) на экспорт и импорт интерфейсов. Величина этих затрат может быть значительна, так как многие клиентские процессы существуют короткое время, а при каждом старте процесса процедура импорта интерфейса должна быть снова выполнена. Кроме того, в больших распределенных системах может стать узким местом программа binder, а создание нескольких программ аналогичного назначения также увеличивает накладные расходы на создание и синхронизацию процессов.

Семантика RPC в случае отказов

В идеале RPC должен функционировать правильно и в случае отказов. Рассмотрим следующие классы отказов:

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

2. Потерян запрос от клиента к серверу. Самое простое решение - через определенное время повторить запрос.

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

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

• Ждать до тех пор, пока сервер не перезагрузится и пытаться выполнить операцию снова. Этот подход гарантирует, что RPC был выполнен до конца по крайней мере один раз, а возможно и более.

• Сразу сообщить приложению об ошибке. Этот подход гарантирует, что RPC был выполнен не более одного раза.

• Третий подход не гарантирует ничего. Когда сервер отказывает, клиенту не оказывается никакой поддержки. RPC может быть или не выполнен вообще, или выполнен много раз. Во всяком случае этот способ очень легко реализовать.

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

1. Клиент потерпел аварию после отсылки запроса. В этом случае выполняются вычисления результатов, которых никто не ожидает. Такие вычисления называют "сиротами". Наличие сирот может вызвать различные проблемы: непроизводительные затраты процессорного времени, блокирование ресурсов, подмена ответа на текущий запрос ответом на запрос, который был выдан клиентской машиной еще до перезапуска системы.

Как поступать с сиротами? Рассмотрим 4 возможных решения.

• Уничтожение. До того, как клиентский стаб посылает RPC-сообщение, он делает отметку в журнале, оповещая о том, что он будет сейчас делать. Журнал хранится на диске или в другой памяти, устойчивой к сбоям. После аварии система перезагружается, журнал анализируется и сироты ликвидируются. К недостаткам такого подхода относятся, во-первых, повышенные затраты, связанные с записью о каждом RPC на диск, а, во-вторых, возможная неэффективность из-за появления сирот второго поколения, порожденных RPC-вызовами, выданными сиротами первого поколения.

• Перевоплощение. В этом случае все проблемы решаются без использования записи на диск. Метод состоит в делении времени на последовательно пронумерованные периоды. Когда клиент перезагружается, он передает широковещательное сообщение всем машинам о начале нового периода. После приема этого сообщения все удаленные вычисления ликвидируются. Конечно, если сеть сегментированная, то некоторые сироты могут и уцелеть.

• Мягкое перевоплощение аналогично предыдущему случаю, за исключением того, что отыскиваются и уничтожаются не все удаленные вычисления, а только вычисления перезагружающегося клиента.

• Истечение срока. Каждому запросу отводится стандартный отрезок времени Т, в течение которого он должен быть выполнен. Если запрос не выполняется за отведенное время, то выделяется дополнительный квант. Хотя это и требует дополнительной работы, но если после аварии клиента сервер ждет в течение интервала Т до перезагрузки клиента, то все сироты обязательно уничтожаются.

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

20 Протоколы TCP/IP

TCP/IP - это два основных сетевых пpотокола Internet. Часто это название используют и для обозначения сетей, pаботающих на их основе. Пpотокол IP (Internet Protocol - IP v4) обеспечивает маpшpутизацию (доставку по адpесу) сетевых пакетов. Пpотокол TCP (Transfer Control Protocol) обеспечивает установление надежного соединения между двумя машинами и собственно пеpедачу данных, контpолиpуя оптимальный pазмеp пакета пеpедаваемых данных и осуществляя пеpепосылку в случае сбоя. Число одновpеменно устанавливаемых соединений между абонентами сети не огpаничивается, т. е. любая машина может в некоторый промежуток времени обмениваться данными с любым количеством дpугих машин по одной физической линии.

Дpугое важное пpеимущество сети с протоколами TCP/IP состоит в том, что по нему могут быть объединены машины с pазной аpхитектуpой и разными опеpационными системами, напpимеp Unix, VAX VMS, MacOS, MS-DOS, MS Windows и т.д. Пpичем машины одной системы пpи помощи сетевой файловой системы NFS (Net File System) могут подключать к себе диски с файловой системой совсем дpугой ОС и опеpиpовать "чужими" файлами как своими.

Протоколы TCP/IP (Transmission Control Protocol/Internet Protocol) являются базовыми транспортным и сетевым протоколами в OS UNIX. В заголовке TCP/IP пакета указывается:

IP-адрес отправителя

IP-адрес получателя

Номер порта (Фактически - номер прикладной программы,

которой этот пакет предназначен)

Пакеты TCP/IP имеют уникальную особенность добраться до адресата, пройдя сквозь разнородные в том числе и локальные сети, используя разнообразные физические носители.Маршрутизацию IP-пакета (переброску его в требуемую сеть) осуществляют на добровольных началах компьютеры, входящие в TCP/IP сеть.

Протокол IP - это протокол, описывающий формат пакета данных, передаваемого по сети.

Следующий простой пример можетн прояснить, каким образом происходит передача данных и передача данных. Когда Вы получаете телеграмму, весь текст в ней (и адрес, и сообщение) написан на ленте подряд, но есть правила, позволяющие понять, где тут адрес, а где сообщение. Аналогично, пакет в компьютерной сети представляет собой поток битов, а протокол IP определяет, где адрес и прочая служебная информация, а где сами передаваемые данные. Таким образом, протокол IP в эталонной модели ISO/OSI является протоколомсетевого (3) уровня.

Протокол TCP - это протокол следующего уровня, предназначеный для контроля передачи и целостности передаваемой информации.

Когда Вы не расслышали, что сказал Вам собеседник в телефонном разговоре, Вы просите его повторить сказанное. Приблизительно этим занимается и протокол TCP применительно к компьютерным сетям. Компьютеры обмениваются пакетами протокола IP, контролируют их передачу по протоколу TCP и, объединяясь в глобальную сеть, образуют Интернет. Протокол TCP является протоколом транспортного (4) уровня

21 создание канала связи между клиентом и сервером

22 передача и прием данных

int info = pvm_send( int tid, int msgtag)

call pvmfsend( tid, msgtag, info)

int info = pvm_mcast( int *tids, int ntask, int msgtag)

call pvmfmcast( ntask, tids, msgtag, info)

Подпрограмма pvm_send() помечает сообщение целочисленным идентификатором msgtag и передает его непосредственно процессу TID.

Подпрограмма pvm_mcast() помечает сообщение целочисленным идентификатором msgtag и широковещательно передает это сообщение всем задачам, указанным в целочисленном массиве tids (исключая себя). Массив tids имеет длину ntask.

int info = pvm_psend( int tid, int msgtag, void *vp,

    int cnt, int type)

call pvmfpsend( tid, msgtag, xp, cnt, type, info)

Подпрограмма pvm_psend() упаковывает и посылает массив данных указанного типа задаче, идентифицированной TID. Предопределенные типы данных на Фортране такие же, как и для pvmfpack(). В языке C аргумент type может иметь любое из следующих значений:

PVM поддерживает несколько методов приема сообщений в задаче. В PVM нет точного соответствия функций, например, применение pvm_send не обязательно требует примененияpvm_recv. Каждая из следующих подпрограмм может быть вызвана для любого из поступающих сообщений вне зависимости от того, как оно было передано (или передано широковещательно).

int bufid = pvm_recv( int tid, int msgtag)

call pvmfrecv( tid, msgtag, bufid)

Эта подпрограмма блокирующего приема будет ожидать до тех пор, пока от задачи с TID не поступит сообщение с меткой msgtag. Значение -1 в msgtid или TID означает ``все задачи'' (специальный символ). После поступления она помещает сообщение в новый создаваемый активный буфер приема. Предыдущий активный буфер приема очищается, если он не был сохранен вызовом pvm_setrbuf().

int bufid = pvm_nrecv(int tid, int msgtag)

call pvmfnrecv( tid, msgtag, bufid)

Если запрашиваемое сообщение не прибыло, то неблокирующий прием pvm_nrecv() при завершении вернет код, равный 0. Эта подпрограмма может вызываться сколько угодно раз для определенного сообщения - с целью проверки его прибытия - в промежутках выполнения работы программы. Если же возможной в данной ситуации работы не осталось, для того же сообщения можно воспользоваться блокирующим приемом pvm_recv(). Если сообщение с меткой msgtag поступило от задачи с TID, pvm_nrecv() помещает это сообщение в новый активный буфер (который она создает) и возвращает идентификатор данного буфера. Предыдущий активный буфер приема очищается, если он не был сохранен вызовомpvm_setrbuf(). Значение -1 в msgtid или TID означает ``все задачи'' (специальный символ).

int bufid = pvm_probe( int tid, int msgtag)

call pvmfprobe( tid, msgtag, bufid)

Если запрашиваемое сообщение не прибыло, то pvm_probe() возвращает bufid, равный 0. В противном случае она возвращает bufid сообщения, но не ``принимает'' его. Эта подпрограмма может вызываться сколько угодно раз для определенного сообщения - с целью проверки его прибытия - в промежутках выполнения работы. Дополнительно может быть вызвана pvmbufinfo() с возвращенным bufid - для получения информации о сообщении перед его непосредственным приемом.

int bufid = pvm_trecv( int tid, int msgtag,

    struct timeval *tmout)

call pvmftrecv( tid, msgtag, sec, usec, bufid)

PVM также поддерживает версию приема с тайм-аутом. Рассмотрим случай, при котором сообщение не прибывает никогда (из-за ошибки или сбоя): подпрограмма pvm_recv может заблокироваться навечно. Для избежания такой ситуации пользователь может захотеть ``прекратить'' ожидание после истечения фиксированного временного отрезка. Подпрограммаpvm_trecv() предоставляет пользователю возможность указать период тайм-аута. Если этот период очень велик, то pvm_trecv() действует подобно pvm_recv. Если же период тайм-аута установлен в ноль, то pvm_trecv() действует подобно pvm_nrecv. Так, pvm_trecv ``заполняет пробел'' между функциями блокирующего и неблокирующего приема.

Подпрограмма pvm_bufinfo() возвращает msgtag, TID источника и длину в байтах сообщения, идентифицированного с помощью bufid. Она может применяться для установления метки и источника сообщений, которые были приняты с использованием специальных символов.

int info = pvm_bufinfo( int bufid, int *bytes,

    int *msgtag, int *tid)

call pvmfbufinfo( bufid, bytes, msgtag, tid, info)

Подпрограмма pvm_precv() сочетает в себе функции блокирующего приема и распаковки буфера приема. Она не возвращает bufid. Вместо него она возвращает действительные значения TID, msgtag и cnt.

int info = pvm_precv( int tid, int msgtag, void *vp,

    int cnt, int type, int *rtid, int *rtag,

    int *rcnt)

call pvmfprecv( tid, msgtag, xp, cnt, type, rtid, rtag,

    rcnt, info)

Подпрограмма pvm_recvf() модифицирует контекст работы принимающих функций и может быть использована для ``расширения'' PVM. Используемый по умолчанию контекст приема заключается в соответствии источника и тега сообщения. Он может быть модифицирован для любой определяемой пользователем функции сравнения. Подпрограммы, соответствующей pvm_recvf(), с интерфейсом на Фортране - нет.

23 интерфейс сетевой базовой системы ввода вывода

Историческая Справка

          Когда в 1984 году было впервые объявлено о Сети ПЭВМ IBM (IBM PC Network), возник вопрос: какое сетевое программное обеспечение реализовала фирма IBM ? Своеобразный ответ на него дали компаниипродавцы ЛВС: они предложили Сети MICROSOFT (Microsoft Networks), думая, что именно это программное обеспечение используется в Сети ПЭВМ (PC Network). Принятие такого решения было обусловлено, в частности, еще и тем, что операционная система MS-DOS фирмы Microsoft стала PC-DOS для компании IBM. (Сети Microsoft (Microsoft Networks) безусловно являются продуктом изготовителей комплексного оборудования. Они не реализованы ни в какой определенной ЛВС - это обусловлено только фирмой-изготовителем комплексного оборудования).

          Та же история повторилась в апреле 1987 года, когда IBM объявила о создании OS/2 одновременно с фирмой Microsoft, которая заявила о своем новом продукте - Администраторе ЛВС (LAN Manager). В течение некоторого времени после этого события компания IBM не разглашала свою новинку - "стратегию спецпроцессора", пока не вышла на рынок с новым своим продуктом - Спецпроцессором ЛВС OS/2 IBM (IBM OS/2 LAN Server). И снова возникли затруднения - как же соотносятся эти два продукта - Спецпроцессор IBM и Администратор Microsoft?

          В настоящей главе рассказывается об эволюции Сетей Microsoft (Microsoft Networks) и Программы ЛВС ПЭВМ IBM (IBM PC LAN Program), начиная с оригинальной разработки и до их реализации в OS/2.

[начало] [оглавление]

Сети Microsoft (Microsoft Networks)

          Только после выпуска Сети ПЭВМ (PC Network) с модулированной передачей фирмы-продавцы и пользователи стали осознавать, что сетевое программное обеспечение в Сети ПЭВМ (которое позднее стало известно как NETBIOS) является несовместимым с Сетями Microsoft (Microsoft Networks) и оно не было создано фирмой Microsoft. В результате, поток продуктов, совместимых с Сетями Micrsoft, о котором объявили многие фирмы-продывцы ЛВС, никогда не был реализован.

          После выпуска cети ПЭВМ (PC Network) фирма Microsoft действительно изменила структуру пользовательских команд в Сетях Microsoft (Microsoft Networks), чтобы достигнуть более тесного соответствия с командами, используемыми IBM. (К примеру, команда CONNECT стала командой NET USE). Фактически, команды Сетей Microsoft являются в значительной степени "подмножеством" команд, используемых в Программе ЛВС ПЭВМ IBM (IBM PC LAN Program).

          Один из компонентов реализации IBM NETBIOS был написан фирмой Microsoft: это непопулярный в настоящее время передресатор. Он тесто связан с PC/MS-DOS в том смысле, что используется протокол Блока сообщений спецпроцессора (SMB) (см. Главу 5), хотя остальная часть Сетей Microsoft и NETBIOS спроектирована таким образом, чтобы обеспечить независимость как от операционной системы, так и от ЛВС. Сети Microsoft (Microsoft Networks) доступны как для Xenix (реализация UNIX, System V фирмой Microsoft), так и для MS-DOS. Переадресатор предназначен для того, чтобы запросы на услуги (например, открытие или распечатка файлов), которые обычно обрабатываются в местном "режиме", были, при необходимости, перехвачены, преобразованы в сетевой запрос и направлены для исполнения спецпроцессору.

          Подобно NETBIOS, Сети Microsoft (Microsoft Networks) предназначены для работы с MS-DOS 3.1 (на ней основан и спецпроцессор и рабочая станция) или же с более высокой версией этой операционной системы. Режимы коллективного использования файлов и режимы блокировки файлов идентичны. Аналогична и расширенная схема поименования: \\имя_спецпроцессора\каталог\файл (\\server_name\directory\file).

[начало] [оглавление]

Сети Microsoft И NETBIOS

          Основное различие между ранней версией Сетей Мicrosoft (Microsoft Networks) и NETBIOS заключается в том, что Сети Microsoft предоставляют интерфейс транспортного уровня, в то время как интерфейс NETBIOS находится на сеансовом уровне. Сети Microsoft также включают специализированной программное обеспечение спецпроцессора и рабочей станции, тогда как Программа ЛВС IBM PC обеспечивает эти и другие функции, включая неспециализированный спецпроцессор.

          Транспортный уровень Сетей Microsoft используется для отправки сообщений через виртуальные каналы. По одному запросу может быть передано до 64 кбайт. Коммуникация (обмен данными) с транспортным уровнем осуществляется посредством прерывания 21H, функция 5BH (напомним, что NETBIOS использует прерывание 21H, функция 5CH). Коммуникация с транспортным уровнем производится посредством установки Блока управления транспортом (Transport Control Block, сокращенно TCB), а затем выполнения прерывания 21H. Блок управления транспортом аналогичен Блоку управления сообщениями (MCB) или Блоку управления сетью (NCB) в NETBIOS. Фактически, многие поля являются общими как для реализации TCB, так и для реализации NCB/MCB. На рис. 6-1 показана структура Блока управления транспортом (TCB).

ИМЯ ПОЛЯ ДЛИНА (байт) и ЗНАЧЕНИЕ ------------------------------------------------------------------- ! COMMAND ! 1 Поле команды ! ! ! ! ------------------------------------------------------------------- ! CID ! 1 Идентификатор команды ! ! ! ! ------------------------------------------------------------------- ! VCID ! 1 Идентификационный номер виртуального канала ! ! ! ! ------------------------------------------------------------------- ! LENGTH ! 2 Размер буфера данных ! ! ! ! ------------------------------------------------------------------- ! BADDR ! 4 Указаталь на адрес буфера сообщения ! ! ! (смещение:сегмент) ! ------------------------------------------------------------------- ! RES1 ! 2 Зарезервированное ! ! ! ! ------------------------------------------------------------------- ! LADDR ! 16 Местный адрес ! ! ! ! ------------------------------------------------------------------- ! RADDR ! 16 Удаленный адрес ! ! ! ! ------------------------------------------------------------------- ! ASYNC ! 4 Указатель на подпрограмму нотификации (объявления)! ! ! адреса (смещение:сегмент) ! ------------------------------------------------------------------- ! LNET ! 4 Местный номер ЛВС ! ! ! ! ------------------------------------------------------------------- ! RNET ! 4 Удаленный номер ЛВС ! ! ! ! ------------------------------------------------------------------- ! RTO ! 1 Тайм-аут получения (шаг равен 500 мсек) ! ! ! ! ------------------------------------------------------------------- ! STO ! 1 Тайм-аут отправки (шаг равен 500 мсек) ! ! ! ! ------------------------------------------------------------------- ! RES2 ! 8 Зарезервированное ! ! ! ! -------------------------------------------------------------------

Рис. 6-1. Блок управления транспортом (TCB).

          Как и для оригинального NETBIOS в Сети ПЭВМ с модулированной передачей (PC Network), сетевой уровень в Сетях Microsoft реализован лишь в минимальной степени. Имеется поддержка для иерархического адреса, состоящего из 4-байтового адреса сети и 16-байтового адреса станции. Также имеется низкоуровневая поддержка для услуги дейтаграмм, позволяющая отправлять/принимать неквитированные пакеты длиной до 512 байт. Изготовитель комплексного оборудования должен решить, как отобразить адреса станций в адресах сети и как реализовать алгоритм маршрутизации, если будет разработан шлюз.

          К сожалению, между Сетями Microsofdt и NETBIOS существует много различий, что затрудняет совместимость этих продуктов. Кроме уже упромянутых различий, несовместимыми являются и две схемы поименования. NETBIOS позоляет иметь несколько имен, динамически переназначать имена и транслировать их; в то сремя как в Сетях Microsoft требуется, чтобы администратор присваивал только одно логическое имя каждому физическому адресу.

          Несмотря на различия в обеих реализациях, у них есть один общий недостаток: обе основываются на MS-DOS для выполнения услуг в файловом процессоре. Другими словами, на них влияют недостатки операционной системы - однопользовательской и "однозадачной". В первой редакции данной книги мы написали следующее: "Не совсем ясно, сможет ли 'многозадачная' версия DOS решить эту проблему, потому что для успешной своей работы она более чем вероятно НЕ будет совместима с предыдущими версиями DOS,что полностью обезоружит пять миллионов владельцев ПЭВМ". Как оказалось, OS/2 поддерживает только некоторые команды DOS и лежащую в основе DOS файловую структуру, что не устраняет трудности в работе для любого спецпроцессора ЛВС, действующего под управлением OS/2. (Метод, имеющийся в DOS, - метод использования таблицы размещения (записей) файла (FAT) потребует проведения интенсивного табличного поиска при открытии, закрытии и поддержании файла).

          Некоторые фирмы-продавцы, объявившие о поддержке Сетей Microsoft, выпустили на рынок промышленные версии для своих сетей. Многие из них предлагают также и NETBIOS, т.к. Сети Microsoft включают "образец" эмулятора NETBIOS, который фирмы-изготовители комплексного оборудования могут предлагать наряду со своими продуктами. Получилось так, что первоначальная полезность Сетей Microsoft в чистой среде MS-DOS была некоторым образом ограничена. Первоначально Сети Microsoft были для ЛВС с комбинацией операционных систем DOS и Xenix.

[начало] [оглавление]

Администратор ЛВС

          С появлением Администратора ЛВС (LAN Manager) Microsoft (одновременно с PS/2 и OS/2), переадресатор стал называться Генератором запросов (Запросчиком), а NETBIOS стал интерфейсом прикладного программирования (API) для OS/2. Администратор ЛВС работает под управлением OS/2 на PC AT или PS/2 Модель 50 и выше с процессором 80286 или 80386. ПЭВМ рабочей стванции может действовать либо с МS-DOS и Программой ЛВС ПЭВМ (PC LAN Program), которая требует наличия NETBIOS, либо с OS/2 и новым интерфейсом прикладного программирования (API) NETBIOS. Администратор ЛВС OS/2 Microsoft (созданный совместно с 3Com) позволяет пользователям соединять системы ПЭВМ под управлением либо Microsoft OS/2, либо MS-DOS вместе в единую цепь. Системы под управлением Microsoft XENIX и XENIX Net могут быть также подсоединены к этой же сети.

          В подобной сети система на основе Microsoft OS/2 может работать одновременно и как рабочая станция и как спецпроцессор; Системы MS-DOS работающие в Сетях Microsoft, могут действовать как спецпроцессор или рабочая станция. Системы на основе XENIX могут работать и как спецпроцессор и как рабочая станция одновременно.

          Администратор ЛВС OS/2 Microsoft дает такие сетевые возможности, как прозрачное совместное использование файлов и печати, средства защиты пользователя и инструментальные средства управления сетью. Вследствие того, что Администратор ЛВС OS/2 Microsoft тесно связан с операционной системой MS OS/2, интерфейсы программирования работают во всей сети как прозрачные. Средство межпроцессовой коммуникации (IPC) облегчает процесс непосредственного обмена данными (коммуникации между прикладными программами, хотя они и находятся на разных машинах в сети. Разработчики прикладных программ смогут создать единую версию программного продукта, который может работать как на отдельной машине, так и на нескольких мамшинах, соединенных Администратором ЛВС OS/2 Microsoft. Такие фирмы как Novell и 3Com предложили свои собственные версии Средства межпроцессовой коммуникации (IPC) до OS/2.

          Администратор ЛВС OS/2 Microsoft полностью совместим с существующими продуктами Сетей Microsoft как для операционной системы MS-DOS, так и для XENIX. Это позволяет новым системам под управлением MS-DOS взаимодействовать с существующими сетями, поддерживающими Сети Microsoft.

          Большинство фирм-изготовителей комплексного оборудования, предлагающих Сети Microsoft (включая HEWLETT PACKARD, TandemTandem, DEC, Ungermann-Bass, 3Com/Bridge, AT&T, Nothern Telecom, AST Research, Apricot, Seimens, Bull, Intel, NEC Japan, XeroxXerox, SMT Goupil Research Machines и Digital Microsystems) также будут предлагать Администратор ЛВС Microsoft. Фирма IBM - заметное исключение из этого списка. Несмотря на то, что Сети Microsoft и Программа ЛВС ПЭВМ/NETBIOS имеют много общего, IBM не собирается поддерживвать Администратор ЛВС, планируя позже предложить программное обеспечение для Спецпроцессора ЛВС OS/2 (LAN Server). Еще одно различие между Microsoft и IBM - Расширенная версия OS/2 IBM (IBM OS/2 Extended Edition), которая стала собственной версией OS/2, созданной фирмой IBM. От изготовителей комплексного оборудования OS/2 Microsoft будет зависеть, оказать ли поддержку Расширенной версии IBM. Многие фирмы оснащают Стандартную версию дополнениями, например, пакетом APPC/PC.

[начало] [оглавление]

Взаимодействие Администратора ЛВС И API NETBIOS

          Интерфейсы прикладного программирования (API) для OS/2 Microsoft предоставляют доступ к сетевым функциям и используются языками высокого уровня. API обеспечивает два вида функций:

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

          Интерфейс прикладного программирования (API) Администратора ЛВС имеет те же ограничения, что и стандартный API DOS. API использует программную модель удаленного вызова процедуры, чтобы обеспечить управление удаленными спецпроцессорами и их ресурсами как местными. Такие вызовы принимают параметр имени спецпроцессора, который указывает цель операции. Для того, чтобы предотвратить несанкционированное использование, некоторые функции, вызванные удаленно, выполняются только, если запрашивающий пользователь имеет преимущество в управлении данным спецпроцессором.

          Управляющая программа (драйвер) NETBIOS - одна из категорий, определенная Интерфейсом прикладного программирования (API) Администратора ЛВС. Администратор ЛВС определяет и другие категории. Просто перечислим их.

Рабочая станция (WORKSTATION) - Информация о конфигурации рабочей станции.

Использование переназначения - Соединение удаленного (REDIRECT USE) устройства рабочей станции

Сообщения (MESSAGING) - Отправка и прием сообщений от пользователя к пользователю

Тревога (ALERT) - Управляет и поднимает тревогу в сети

Каналы (PIPES) - Двустроронняя коммуникация процессов

Почтовые участки (MAILSLOTS) - Односторонняя коммуникация процессов

Параметры пользователя - Сохраняет/восстанавливает (PROFILE) активное использование/совместное использование

Конфигурация (CONFIG) - Устанавливает элементы из файла LANMAN.INI

Спецпроцессор (SERVER) - Конфигурация спецпроцессора и статистические данные о нем

Совместное использование - Совместное использование файла (SHARES) и устройства спецпроцессора

Сеансы (SESSIONS) - Машинные сеансы спецпроцессора

Cоединения (CONNECTIONS) - Пользовательские соединения спецпроцессора

Файлы (FILES) - Открытые файлы спецпроцессора Регистрация (AUDITING) - Регистрация в контрольном журнале

Регистрация ошибок - Регистрация системных ошибок (ERROR LOGGING)

Символьные устройства - Соединения с удаленными (CHAR DEVICES) символьными устройствами

Очереди печати (PRINT QUEUES) - Очереди заданий системы буферизации потоков I/O

Задания печати (PRINT JOBS) - Задания печати системы буферизации

Назначения печати - Виртуальные устройства в (PRINT DESTINATIONS) системе буферизации

Разрешения на доступ - Разрешения на доступ к файлам (ACCESS PERMISSIONS) и другим ресурсам

Пользователи (USERS) - Разрешения на пользование файлами и групповое членство

Статистика (STATISTICS) - Статистические данные о работе рабочей станции и спецпроцессора

Удаленные (REMOTE) - Удаленные функции, такие как удаленное выполнение программы, копирование файлов и передвижение файлов

Смешанные (MISCELLANEOUS) - Время дня в сети и т.п.

          Доступ к управляющей программе NETBIOS осуществляется вызовом Enum. Вызовы Enum перечисляют тип ресурса, является ли он именами пользователей, заданиями в очереди, очередями в спецпроцессоре и т.д. Вызовы всегда возвращают целое число частей ответа фиксированной длины. Если буфер пользователя слишком мал,некоторые данные переменной длины не возвращаются, вероятнее всего,для последнего элемента, хотя это и не обязательно. Кодом возврата является "больше данных", включая и данные переменной длины. Этот пераметр показывает количество возвращенных "порций" фиксированной длины. Некоторые или все из них могут иметь только часть соответствующих переменных данных, возвращаемых вместе с ними.

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

Уровень 0 ---------

struct netbios_info_0 {char nb_net_name [16] }; /* nb_net_name is 16 character NETBIOS name */

Уровень 1 ---------

struct netbios_info_1 {char nb_ntet_name [16]; char nb_driver_name [9]; /* OS/2 device driver name */ unsigned byte nb_lana_num; /* lan adapter number */ unsigned short nb_driver_type; /* 1 = ncb, 2 = mcb */ unsigned short nb_net_status; /* bit 0 on = net started */ /* bits 14/15 opcodes as follows: */ /* 0 = net not opened */ /* 1 = open in regular mode */ /* 2 = open in privileged mode */ /* 3 = open in exclusive mode */ unsigned long nb_net_bandeidth; /* network bandwidth bits/s */ unsigned short nb_max_sess; /* max number of sessions */ unsigned short nb_max_ncbs; /* max number of outstanding ncbs */ unsigned short nb_max_names; /* max number of names */

[начало] [оглавление]

Вызовы Процедур

Вызов Процедуры NETBIOSENUM

Назначение: перечислить управляющие программы (драйверы) NETBIOS

Условие вызова

init far pascal NetBiosEnum(servername,level, buf,buflen,intritsread,totalentries) char far * servername; /* name of tart PC (null if local) */ char far * buf; /* pointer to info buffer */ unsigned short buflen; /* byte length of info buffer */ unsigned short far * entriesread; /* # of entries supplied on return */ unsigned short far * totalentries; /* total # of entries available */

Величина возврата

Содержимое буфера при возврате (формат для одного элемента) может быть одно из следующих:

Уровень 0 содержит "struct_netbios_info_0", Уровень 1 содержит "struct_netbios_info-1".

Возврат ошибки

Возврат функции 0 означает, что все нормально. Возможными возвратами ошибок могут быть следующие:

- сеть не начала работать; - устройство не найдено; - спецпроцессор не найден; - сбой в обмене данными с удаленным спецпроцессором.

Вызов Процедуры NETBIOSGETINFO

Назначение: Получение информации о данной управляющей программе (драйвере) NETBIOS.

Условие вызова

int far pascal netbiosgetinfo (servername,netdevname,level,buf,buflen) int far pascal netbiosgetinfo (servername,netbiosname,level,buf,buflen) char far * servername; /* name of target pc (null if local) */ char far * netbiosname; /* netbios network name */ short level; /* level of info requested */ char far * buf; /* pointer to info buffer */ unsigned short buflen; /* byte length of info buffer */

Уровень 1 содержит "struct netbios_info_1".

Возврат ошибки

Функция возвращает 0, если все нормально. Ниже возможны даны возможные возвраты онибок:

- слишком мал размер буфера для фиксированных полей; - устройство не найдено; - спецпроцессор не найден; - сбой в обмене данными с удаленным спецпроцессором.

Вызов Процедуры NETBIOSOPEN

Назначение: Получает handle для отправки управляющей программе NETBIOS.

Описание

          Вызов этой процедуры создает handle для отправки Блоков управления сетью (NCB) в управляющую программу (драйвер) NETBIOS. Программа может определить, какими эти имена являются, путем вызова NETBIOSENUM. Нулевая (пустая) строка может быть использована как имя устройства для скрытой ссылки на первую установленную управляющую программу NETBIOS.

NETBIOSOPT определяет открытые опции, которые включают в себя:

Режим доступа: 1. Обычный (регулярный) (mask 0x3) 2. Привилегированный 3. Исключительный           Режим доступа определяет каким образом пользователь хочет разделить доступ к управляющей программе NETBIOS с другими процедурами. В регулярном режиме драйвер (управляющая программа) может быть открыт любым количеством процедур. Помимо этих процессов, еще один процесс может открывать драйвер в привилегированном режиме. Один и только один процесс может открывать драйвер в исключительном режиме. В зависимости от режима доступа операции Блока управления сетью (NCB) ограничены.

Режим Описание

          Регулярный Не позволяет переустанавливать, получать широковещательные дейтаграммы, получать "от любого к любому" Блоки управления сетью (NCB), или использовать постоянные имена в любом Блоке управления сетью (NCB).

          Превилеги- Не позвроляет переустанавливать или полурованный чать NCB "от любого к любому".

Исключительный Позволяет выполнять любые операции NCB.

Условие вызова

int far pascal netbiosopen (netbiosname, netreserved, netopenopt, nethandle) char far * netbiosname; /* Name of NETBIOS network */ char far * netreserved; /* reserved pointer; must be 0 */ unsigned short netopenopt; /* open options */ int far * nethandle; /* word for returned handle */

Возврат ошибки

Функция возвращает 0, если все нормально. Возможными возвратами ошибок являются:

- Управляющая программа (драйвер) NETBIOS не существует; - неверная опция; - открытый режим противоречит существующему; - недоступны ресурсы системы.

HANDLES NETBIOS являются связями процесс-драйвер. Только тот процесс, который создал данный драйвер, может его использовать.

Вызов Процедуры NETBIOSCLOSE

Назначение: Закрывает handle драйвера NETBIOS.

Описание

          Вызов этой процедуры завершает доступ к драйверу NETBIOS, делает "ошибочным" handle и отменяет все Блоки управления сетью, вызванные процессом, который создал данный идентификатор.

Условие вызова

int far pascal netbiosclose (nethandle, netreserved) int nethandle; /* handle to close */ short netreserved; /* reserved, must be zero */

Возврат ошибки

Функция возвращает 0, если все нормально. Возможные возвраты ошибок:

- неверный handle.

Вызов Процедуры NETBIOSSUBMIT

Назначение

          Передает Блок управления сетью (NCB) драйверу NETBIOS. handle 0 относится к первому установленному драйверу NETBIOS. Этот драйвер автоматически подвергнут действию процедуры NETBIOSOPEN при необходимости (в регулярном режиме) сразу же, как только вызов NETBIOS обратится к нему используя идентификатор 0.

          NETNCB указывает на Блок управления сетью (NCB), который должен быть выполнен (несцепленный NCB) или на слово-связку, предшествующее NCB (сцепленный NCB).

NETNCBOPT определяет опции обработки NCB, которые включают:

Сцепление: 0 отдельных NCB передается (mask 0x3) 1 отдельный NCB с повторением при ошибке 2 NCB сцепливаются с продолжением при ошибке 2 NCB сцепливаются с остановкой при ошибке

          Опции сцепления определяют, передается ли отдельный NCB или цепочка NCB. Отдельный Блок NCB может быть выполнен с опцией повторной передачи при ошибке, - в этом случае ядро сети выдает NCB установленное количество раз в ответ на следующие ошибки:

09H - нет доступных ресурсов; 12H - отказано в открытии сеанса; 21H - занят интерфейс.

          Сцепленные NCB должны быть в одном и том же сегменте и должны быть связаны 16-битовым указателем смещения, который предшествует NCB. Смещение 0xFFFF определяет конец сцепливания.

          Хотя может быть сцеплена любая последовательность команд NCB, не все возможности являются приемлимыми. Например, Вы не можете открыть сеанс и послать пакет данных по нему, связав команды SEND и CALL. Поле NCB_LSN, возвращенное по команде CALL NCB, должно быть скопировано в SEND NCB - ядро сети не поддерживает этого автоматически. Блоки управления сетью (NCB) в цепочке "с продолжением при ошибке" выполняются независимо один от другого, и вне зависимости от ошибок в цепочке; подобная цепочка просто обеспечивает быструю передачу набора Блоков NCB драйверу. Блоки, которые не были обработаны вследствие ошибки ранее в цепи, будут иметь свое поле NCB-CMD-CPLT установленное как 0xB (Команда отменена). Этот тип цепочки обычно должен иметь только режим ожидания. Неожидаемые Блоки NCB принимаются, но в этом случае именно немедленный (а не конечный) возврат определяет, продолжится или остановится процесс.

Условие вызова

int far pascal netbiossubmit (nethandle, netncbopt, netncb) int nethandle; /* handle to issue ncb against */ unsigned short netncbopt; /* option flags */ struct ncb far * netncb; /* Address of NCB */

Функция возвращает 0, если все нормально. Возможными возвратами ошибок являются:

- неверный handle; - неправильные опции; - отказано в доступе; - недоступны ресурсы драйвера; - определенные NETBIOS коды немедленного возврата (неожидаемый NCB); - определенные NETBIOS коды конечного возврата (режим ожидания NCB).

[начало] [оглавление]

Функционирование

          Ядро Сетей Microsoft (Microsoft Networks), используемое Администратором ЛВС (LAN Manager), поддерживает несколько управляющих программ (драйверов) NETBIOS посредством рассмотрения каждой как поименованного устанавливаемого драйвера устройства, который может быть открыт и закрыт. Прикладные программы, использующие один и тот же драйвер NETBIOS, могут получать совместный доступ к именам и сеансам, которые они создали, просто путем передачи номера имени или сеанса другому процессу. Это позволяет другим процессам посылать и получать данные от имени процессов-"владельцев", или же высвобождать совместно используемые имена и сеансы.

          В защищенном режиме Блоки управления сетью (NCB) NETBIOS обрабатываются также, как и под управлением MS-DOS 3.X, посредством прерывания 5C и 2A, за исключением следующего:

1. Поле NCB_POST@ теперь содержит handle семафора системы, а не подпрограмму асинхронной нотификации (объявления). Ядро сети освободит этот семафор, когда завершится режим неожидания NCB.Иденhandle семафора, равный 0, считается пустым и не освобождается.

2. Поля NCB_POST@ и NCB_BUFFER@ временно изменены ядром сети во время обработки Блока управления сетью (NCB). Прикладные программы не должны зависеть от величин этих полей, пока не будет завершен NCB.

3. Некоторые функции NCB не разрешены, в зависимости от режима доступа, определенного вызовом NETBIOSOPEN.

4. Процессы могут коллективно использовать ресурсы NETBIOS, которыми они располагают, просто путем передачи номеров требуемых имен и сеансов другим процессам (как об этом сказамно выше). Получающие процессы просто используют номера общих имен или сеансов в Блоках управления сетью (NCB), которые они создают. Такие процессы должны, безусловно,послать Блоки NCB против handle, которые они сами создали (процедурой NETBIOSOPEN), в этот же драйвер.

[начало] [оглавление]

Программа ЛВС ПЭВМ

          Программа ЛВС ПЭВМ IBM (IBM PC LAN Program), ранее носившая имя Программа Сети ПЭВМ IBM (IBM PC Network Program) была первоначально предназначена для работы с DOS 3.1 и Сетью ПЭВМ IBM (IBM PC Network) с модулированной передачей. Программа ЛВС ПЭВМ требует поддержки NETBIOS посредством Служебной Программы ЛВС ПЭВМ (PC LAN Support Program) и DOS 3.2 или выше, для работы в ЭКС Token-Ring.

          Программа ЛВС ПЭВМ (PC LAN Program) состоит из одного большого файла, который может быть вызван одним из четырех способов: пользователь выполняет команду NET START,а затем определяет переадресатор, получатель, отправитель или спецпроцессор. Первые три варианта (переадресатор,получатель, отправитель) предназначены для рабочих станций, а последний (спецпроцессор) является неспециализированным файловым процессором/процессором печати, который работает как фоновая задача на рабочей станции. На рис. 6-2 показан образец такой реализации, где одна ПЭВМ служит как файловый процессор, а другая - как процессор печати.

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

          Процедура установки управляется меню. Если установка произведена, с Программой Сети ПЭВМ (PC Network Program) можно работать либо набирая команды на клавиатуре по подсказке DOS, либо с помощью меню.

          Первоначальная версия программы ЛВС ПЭВМ подверглась жесткой критике - главным образом из-за проблем, связанных с производительностью. Эта проблема обусловлена тем, что, в отличие от NetWare фирмы Novell, Программа ЛВС ПЭВМ основывается на DOS для работы с файлами и печатью. Но с совершенствованием операционной системы и появлением OS/2, эта проблема потеряла свою остроту. Например, DOS 3.3 имеет дополнительно таблицу размещения записей файла (FAT) (команду FASTOPEN). Весия 1.3 Программы ЛВС ПЭВМ (PC LAN Program) имеет следующие свойства, которые облегчили по сравнению с первоначальной версией этой программы и проблему управления: контролируемый паролем доступ к спецпроцессору; централизированное определение ресурсов и управление ими, включая установку времени/даты на главном спецпроцессоре для синхронизации даты и времени на всех спецпроцессорах и рабочих станциях, для управления печатью, определения пользователей и привилегий, а также для управления меню выбора прикладных программ для отдельных пользователей; доступ администратора к ресурсам с любой рабочей станции, поддержка для удаленной загрузки программ и операционной системы (т.е. поддержка для рабочих станций, не имеющих дисков); возможность просматривать начавших сеанс пользователей, и, наконец, выбор печати, очередность и отображение состояния для удаленных рабочих станций. Версия 1.3 также обладает повышенной производительностью работы.

[начало] [оглавление]

Спецпроцессор ЛВС

          Спецпроцессор ЛВС OS/2 IBM (LAN Server) использует NETBIOS для обмена данными (коммуникации) в ЛВС. Спецпроцессор обеспечивает, как для прикладных программ DOS (посредством Программы ЛВС ПЭВМ), так и для прикладных программ OS/2, совместное использование ресурсов - дисков, печатающих устройств и подсоединенных устройств, плюс средства для определения, управления и руководства доступом к ресурсам ЛВС, наряду с повышенной защитой и управлением печатью (до восьми печатающих устройств). Эти преимущества сходны с теми, которые обеспечиваются Программой ЛВС ПЭВМ (PC LAN Program), за исключением того, что защита файлов снижена до файлового уровня. Для работы Спецпроцессора ЛВС требуется Расширеная версия OS/2 (Extended Edition). Спецпроцессор ЛВС также обеспечивает удаленнрое выполнение программ.

          Часть программного обеспечения Спецпроцессора ЛВС бала создана фирмой Microsoft (в основном переадресатор). Фирма IBM не реализовала многие из Интерфейсов прикладного программирования (API) Microsoft в Администраторе ЛВС (LAN Manager), в частности, Средства межпроцессовой коммуникации, которые несовместимы с Прикладной архитектурой систем (Systems Application Architecture - SAA). Вместо этого, для разработки распределенных прикладных программ необходимо использовать APPC/PC (Перспективное межпрограммное взаимодействие/ПЭВМ), включенное вместе с Расширеной Версией OS/2, особенно в ЭКС Token-Ring со смешанными ЭВМ. Для ЛВС ПЭВМ эта проблема не столь остра - в них можно использовать Администратор ЛВС или другие продукты на основе спецпроцессора, чтобы обеспечить совместимость продуктов. Крупные фирмы, такие как 3Com, Banyan и Novell, предлагают, по меньшей мере, некоторый уровень совместимости (как, например, APPC) с Расширенной Версией OS/2 и Спецпроцессором ЛВС OS/2.

          Таким образом, создается впечатление, что компания IBM рассматривает Спецпроцессор ЛВС как средство перехода от DOS к OS/2. В этом убеждает и тот факт, что Спецпроцессор ЛВС работает под управлением OS/2 и обслуживает как Программу ЛВС ПЭВМ (PC LAN Program) на основе DOS, так и эмулятор NETBIOS OS/2.

25 внутренние механизмы сервера БД

Хотя данный материал предлагает некоторые рекомендации по конфигурированию систем, полезность этих рекомендаций в значительной степени зависит от анализа самого приложения. Важность такого анализа невозможно переоценить! Эффективность работы самого приложения и СУБД намного важнее, чем конфигурация хост-машины. Имеются буквально сотни примеров небольших изменений, проведенных в приложении или в схеме базы данных, которые обеспечивали 100- или 1000-кратное (или даже большее!) увеличение производительности системы. Например, в зависимости от того индексируется или нет таблица с помощью ключа просмотра (lookup key), выполнение оператора select, который запрашивает одну определенную запись, может приводить к тому, что СУБД будет читать из таблицы всего одну запись, либо каждую запись в таблице, содержащей 10 Гбайт данных. Часто для того чтобы оптимально обрабатывать несколько различных шаблонных обращений, генерируемых приложением, таблица должна индексироваться более чем одним ключом или набором ключей. Хорошо осмысленная индексация может иметь весьма существенное воздействие на общую производительность системы (см. разд. 2.2.6.1). После начальной инсталляции системы обязательно нужно произвести сбор статистики о ее работе, чтобы выяснить необходимость внесения изменений в базу данных, даже для приложений собственной разработки или приложений третьих фирм. Часто оказывается возможным улучшить производительность приложения путем реорганизации базы данных даже без обращения к исходному коду приложения.

Другим соображением, которому уделяется недостаточно внимания, но которое часто оказывает огромные воздействие на результирующую производительность системы, являются конфликты по внутренним блокировкам. СУБД должна блокировать доступ к данным при наличии конфликтующих одновременных обращений. Любой другой процесс, который требует доступа к этим данным должен быть отложен до тех пор, пока блокировка не будет снята. Если выбрана неоптимальная стратегия блокировок, то система может оказаться очень плохо работающей.

Каждая СУБД имеет огромное число настраиваемых параметров, некоторые из которых могут серьезно воздействовать на общую производительность системы. Приводимые здесь рекомендации предполагают разумную настройку приложений и СУБД.

Предпосылки выбора

Ниже перечислены вопросы, ответы на которые позволяют обобщить процесс достижения разумной точности конфигурации СУБД:

• Какая используется СУБД? Это "2N" или многопотоковая реализация?

• Какие используются мониторы транзакций (если таковые вообще применяются)?

• Можно ли использовать систему в конфигурации клиент/сервер?

• Сколько одновременно активных пользователей должна поддерживать система?

• Можно ли выделить основной или доминирующий шаблон (образец) обращения к системе? Какие запросы доминируют в нагрузке?

• Какова стратегия индексации? Какие запросы будут оптимизированы с помощью индексации (например, преобразуются для реализации произвольного доступа к данным вместо последовательного) и какие запросы должны быть реализованы с помощью полного или частичного сканирования таблицы?

• Насколько велик чистый размер базы данных?

• Имеется ли достаточное количество дисковых накопителей и главных адаптеров SCSI, сконфигурированных для обеспечения обработки предполагаемой нагрузки? Имеются ли отдельные диски для журналов СУБД и архивов?

• Имеется ли достаточная емкость дисковой памяти для хранения необработанных данных, индексов, временных табличных пространств, а также место для возможного увеличения объема данных?

• Достаточно ли число процессоров, сконфигурированных для работы с предполагаемым количеством пользователей?

• Требуется ли специальная выделенная сеть для организации связи между клиентскими системами и сервером?

• Если предполагаемая нагрузка ориентирована на интенсивное внесение обновлений в базу данных, имеется ли место в конфигурации для NVRAM?

• Согласована ли предполагаемая стратегия резервного копирования с типом, числом и местом размещения устройств резервного копирования SCSI?

Выбор вычислительной модели

В большинстве прикладных систем СУБД можно выделить три логических части: пользовательский интерфейс (средства представления), обеспечивающий функции ввода и отображения данных; некоторую прикладную обработку, характерную для данной предметной области; и собственно сервисы СУБД. Пользовательский интерфейс и прикладная обработка обычно объединены в одном двоичном коде, хотя некоторые из наиболее продвинутых приложений теперь обеспечивают многопотоковую фронтальную обработку, которая отделена от средств представления. Как правило, по мере роста базы данных сервер СУБД реализуется на выделенной системе, чтобы гарантировать минимизацию помех для его работы.

Рис. 2.3. Сравнение модели клиент/сервер с моделью разделения времени  при работе прикладной системы Oracle*Financials.

Если в системе можно реализовать модель вычислений клиент/сервер, отделяющую фронтальную (прикладную) обработку и средства представления от поставщика услуг СУБД, ее использование обычно обеспечивает существенное улучшение общей производительности системы. Такая организация системы позволяет наиболее важному ресурсу (серверу СУБД) работать без помех на своей собственной хост-машине. Это в первую очередь справедливо для систем, в которых работа средств представления связана с управлением сотнями или тысячами терминалов в режиме cbreak. Большинство программ, базирующиеся на curses- (screen-), сегодня используют cbreak-поддержку терминалов.

Режим разделения времени, в отличие от режима клиент/сервер, обычно обеспечивает большую производительность только тогда, когда требования к компоненту представления оказываются очень легкими, или когда одновременная пользовательская нагрузка невелика. Существенно что приложения, в основе компонента представления которых лежат формы, никогда не бывают легковесными. Даже приложения, работающие в диалоговом режиме printf/get обычно значительно более тяжелые, что позволяет оправдать использование конфигураций клиент/сервер. Тест TPC-A определяет возможно наиболее легкое требование приложения/представления (он включает ровно по одному вызову scaf(n) и printf(n)). Следует отметить, что даже тест TPC-A работает только на 5% быстрее в режиме разделения времени. Некоторые сравнительно недавние исследования компании Sun с использованием Oracle*Financials и Oracle 7 показали, что 6-процессорный сервер СУБД на базе SPARCserver 1000 с фронтальной системой на базе SPARCstation 10 Model 512 может поддерживать почти на 40% пользователей больше, чем 8-процессорный SPARCserver 1000, работающий в режиме разделения времени (рис. 2.3).

Рекомендации:

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

• Где это возможно, собственно сервер СУБД должен работать на выделенной системе.

Мониторы обработки транзакций

Использование мониторов обработки транзакций является одним из методов достижения более высокой производительности для имеющейся конфигурации, особенно в режиме клиент/сервер. Иногда мониторы обработки транзакций оказываются очень полезными для создания гетерогенных баз данных, позволяющих хранить некоторые данные в одном формате (например, Oracle на Sun), а другие данные в другом (возможно Ingres на VAX или IMS на мейнфрейме IBM). Кроме того, некоторые TP-мониторы предоставляют сервис для легковесного компонента представления. Хорошо известен TP-монитор компании IBM - Customer Information Control System (CISC). Несколько реализаций CICS (MicroFocus, XDB, VI Systems, Integris) доступны в настоящее время на большинстве аппаратных платформ. Другими известными мониторами являются Tuxedo/T компании USL, TopEnd от NCR и Encina от Transarc.

TP-мониторы представляют собой промежуточный слой программного обеспечения, который располагается между приложением и системой или системами СУБД. При этом приложение должно быть модифицировано так, чтобы оно могло выдавать транзакции, написанные на языке монитора транзакций, а не обращаться прямо к базе данных посредством обычных механизмов (подобных различным формам встроенного SQL). Программисты прикладных систем являются также ответственными за составление файла описания, который отображает транзакции в определенные обращения к базе данных на родном языке обращений нижележащей СУБД (почти для всех СУБД под UNIX это SQL).

Гибкость доступа к данным

Использование мониторов транзакций практически не накладывает каких-либо ограничений на многообразие или сложность запросов доступа к нижележащей СУБД. Например, вполне осмысленной оказывается транзакция, выдающая запрос на набор данных из базы данных DB2 на мейнфрейме IBM, работающей под управлением ОС MVS, а другой набор данных из локальной базы данных Sybase, и затем сливающая оба набора вместе для представления приложению. В результате создается иллюзия того, что данные хранятся в унифицированной базе данных, размещенной в одном и том же "хранилище данных" (data warehause).

В связи с тем, что во многих "старых" (legacy) системах используются мониторы обработки транзакций CICS, мигрирующая часть или все базы данных, связанные с этими системами, могут работать с небольшими изменениями существующих приложений. Все что требуется - это физический перенос данных на новую платформу и модификация описания транзакций для использования данных на новом месте. Однако сложность такого переноса не должна недооцениваться, поскольку он часто требует внесения изменений в представление данных (трансляцию COBOL "PIC 9(12)V99S" в C++ float) и организацию данных (например, из сетевой архитектуры IMS в реляционную архитектуру, используемую почти повсеместно СУБД на базе UNIX). Но возможность сохранить части, связанные с прикладной обработкой и представлением существующих приложений существенно сокращает сложность и риск, связанные с таким переносом.

Вопросы производительности

Помимо достижения определенной гибкости за счет использования TP-мониторов, такая организация оказывается выгодной и с точки зрения увеличения производительности системы. TP-монитор всегда представляет собой многопотоковую программу. Поскольку TP-монитор открывает свое собственное соединение с СУБД, одновременно устраняя необходимость выполнения каждым прикладным процессом прямых запросов к СУБД, число одновременно работающих пользователей СУБД существенно сокращается. В подавляющем большинстве случаев СУБД обслуживает только одного "пользователя" -  TP-монитор. Это особенно важно, когда СУБД относится к классу "2N", поскольку в этом случае используется только один теневой процесс (для обеспечения соединения с TP-монитором), а не по одному процессу на каждый процесс конечного пользователя (рис. 2.4). Это может существенно сократить накладные расходы, связанные с переключением контекста на сервере СУБД.

Рис.2.4. Системы СУБД клиент/сервер сконфигурированные для работы с мониторами  обработки транзакций. Теневой процесс на серверной системе появляется, когда  СУБД использует архитектуру "2N".

TP-мониторы позволяют также улучшить производительность за счет сокращения объема информации, пересылаемой между СУБД и прикладным процессом. Поскольку определенную часть каждой транзакции составляют только минимально требуемые данные, общий объем пересылки данных обычно может быть сокращен. Это особенно важно, когда клиент и сервер соединены между собой посредством достаточно занятой сети и/или сети с низкой полосой пропускания, подобной глобальной сети на спутниковых каналах связи.

Рекомендации:

• TP-мониторы могут рассматриваться как кандидаты для включения в состав системы, когда доступен исходный текст приложения.

• TP-мониторы следует использовать для интеграции в корне отличных источников информации базы данных.

• TP-мониторы особенно полезны для сокращения трафика клиент/сервер на сетях с низкой полосой пропускания или глобальных сетях.

• Применение системе TP-монитора следует рассматривать, когда должно обслуживаться большое количество пользователей и используемая СУБД предпочитает или требует реализации архитектуры "2N".

Подсистема основной памяти

Среди различных компонентов аппаратуры сервера СУБД конфигурация памяти системы обычно имеет самое большое воздействие на ее производительность. Хотя для многих людей память представляется только хранилищем выполняемых программ, большая часть основной памяти в системах СУБД используется в качестве буфера (кэша) данных, позволяющего во многих случаях устранить необходимость выполнения физического ввода/вывода с диска. Поскольку обращение к основной памяти выполняется примерно в 30000 раз быстрее, чем обращение к быстрому диску, минимизация дискового в/в является первостепенно важной задачей. (Обращение к памяти выполняется примерно за 500 нсек даже в самых худших условиях (при наличии промаха при обращении к кэш-памяти, требующего выталкивания модифицированной строки в основную память)). Возможно не будет преувеличением сказать, что "возня" с другими конфигурационными параметрами бесполезна, если в системе не хватает основной памяти. Если нужно создать конфигурацию системы без наличия достаточной информации (обычный случай при покупке новой системы), возможно лучше закупить избыточный объем памяти, чем недооценить его. К счастью, обычно ошибки по конфигурации памяти сравнительно легко исправляются.

Выбор размера буфера ввода/вывода СУБД

Каждая СУБД называет свои буфера данных по разному, но все они выполняют одну и ту же функцию. Oracle называет эту память Глобальной Областью Системы (SGA - System Global Area), в то время как Sybase называет ее Кэшем Разделяемых Данных (Shared Data Cashe). Обычно буфер реализуется как большой массив разделяемой памяти, и его размер определяется специальным параметром в управляющем файле или таблицах СУБД. Размер памяти, необходимый для организации дискового кэша СУБД, меняется в широких пределах от приложения к приложению, но для примерной оценки размера буфера могут быть использованы следующие эмпирические правила.

Практические опыты различных компаний с СУБД Oracle и Sybase показали, что в зависимости от размера базы данных размер области памяти под буфера может варьироваться в очень широких пределах (от 4 Мбайт до более чем 1 Гбайт). Даже указанный больший размер буфера сегодня может быть превышен, поскольку начинают появляться реализованные на базе современных аппаратных платформ значительно большие по размеру базы данных (объемом 50 - 300 Гбайт). Однако следует иметь в виду, что как и при использовании любой кэш-памяти, увеличение размера буфера в конце концов достигает точки насыщения. Очень грубо размер кэша данных можно оценить, выделяя от 50 до 300 Кбайт на каждого пользователя. Каждая из известных систем СУБД имеет механизм сообщений об эффективности использования кэша разделяемых данных. Большинство систем могут также обеспечивать оценку того, какой эффект будет давать увеличение или уменьшение размера кэша.

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

Это означает, что данные, к которым обращения происходят более часто, чем один раз в пять минут, должны кэшироваться в памяти. Соответственно, чтобы оценить размер кэша данных необходимо просуммировать объемы всех данных, которые приложение предполагает использовать более часто, чем один раз в пять минут на уровне всей системы. Поэтому при определении необходимого объема памяти системы следует предусмотреть по крайней мере этот размер кэша данных. Дополнительно, следует зарезервировать еще 5-10% для хранения верхних уровней индексов B-деревьев, хранимых процедур и другой управляющей информации СУБД.

Не стоит волноваться из-за того, что чрезмерное увеличение размера кэша обычно не дает существенного эффекта. Указанные прогнозируемые объемы должны использоваться только для получения грубой оценки необходимой конфигурации системы. Каждая коммерческая СУБД обеспечивает механизм для определения стоимости или преимуществ изменения размера различных кэшей СУБД. Когда система инсталлирована и начинает работать, необходимо использовать эти механизмы для определения эффекта от изменения размеров кэша ввода/вывода СУБД. Следует отметить, что результаты часто могут оказаться удивительными. Например, выделение слишком большого объема памяти для кэша разделяемых данных может лишить пользовательское приложение (или, что еще хуже, сам сервер СУБД) требуемой для нормальной работы памяти. Память может также перераспределяться между кэшем разделяемых данных и пулом виртуальной памяти, используемой операционной системой для буферизации операций файловой системы UNIX (UFS).

Хотя основной целью СУБД на макроуровне является управление томами данных, которые по определению имеют очень большой объем и неизбежно во много раз превышают объем основной памяти, буквально десятки исследований многократно показали, что доступ к данным в общем случае подчиняется правилу "90/10": 90% всех обращений выполняются к 10% данных. Более того, совсем недавние исследования показали, что к "горячим" данным, обращения к которым составляют 90% всех обращений, снова применимо правило 90/10. Таким образом, примерно 80% всех обращений к данным связаны с доступом к примерно 1% агрегатированных данных. Следует отметить, что это отношение включает обращения к внутренним метаданным СУБД (включающих индексы B-деревьев и т.п.), обращения к которым обычно скрыты от прикладного программиста. Хотя желательно иметь коэффициент попаданий в кэш примерно на уровне 95%, по экономическим соображениям невозможно слепо обеспечить объем кэша в памяти, позволяющий разместить 10% всех данных: даже для скромных баз данных объемом 5 Гбайт это потребовало бы увеличения размера основной памяти до 500 Мбайт. Однако обычно всегда возможно обеспечить кэш объемом в 1% всех данных даже для очень больших баз данных. Те же самые 500 Мбайт основной памяти, таким образом, позволяют обслужить базу данных объемом 50 Гбайт, а максимальный размер памяти, например, SPARCcenter 2000 (5 Гбайт) компании Sun достаточен для поддержки баз данных объемом 400-500 Гбайт. (При наличии баз данных такого размера для поддержки неизбежно большого числа пользовательских приложений и т.д. очевидно также потребуется существенная часть этой памяти).

Рекомендации:

• Размер кэша данных СУБД следует выбирать так, чтобы данные, обращения к которым выполняются чаще одного раза в пять минут, могли бы храниться в кэше. Дополнительно необходимо добавить 5-10%.

• Если шаблон (образец) обращений не может быть определен, необходимо обеспечить кэш емкостью, соответствующей по крайней мере 1% от чистого объема данных СУБД (не считая индексов и накладных расходов).

• В крайнем случае размер кэша данных конфигурируется исходя из выделения по 100-150 Кбайт на пользователя.

Дополнительные требования к памяти

Естественно конфигурация системы должна обеспечивать также пространство для традиционного использования памяти. В СУБД на базе UNIX всегда необходимо обеспечить по крайней мере 16 Мбайт для базовой операционной системы. Далее, необходимо предусмотреть пространство объемом 2-4 Мбайт для ряда программ СУБД (программ ведения журнала, проверки согласованного состояния, архиваторов и т.п.) и достаточно пространства для размещения в памяти двоичных кодов приложения. Объем двоичных кодов приложения составляет обычно 1-2 Мбайт, но иногда они могут достигать 16-20 Мбайт. Операционная система обеспечивает режим разделения двоичных кодов между множеством пользующихся ими процессов, поэтому необходимо резервировать пространство только для одной копии. Пространство для размещения самого кода сервера СУБД зависит от общей архитектуры сервера. Для архитектуры "2N" следует выделять по 100-500 Кбайт на пользователя. Многопотоковые архитектуры требуют только 60-150 Кбайт, поскольку они имеют намного меньше процессов и намного меньшие накладные расходы.

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

Процессоры

Потребление процессорных ресурсов очень сильно варьируется в зависимости от используемого приложения, СУБД, индивидуальных пользователей и даже от времени дня.  Например, результаты теста TPC-A показывают, что восьмипроцессорный  SPARCserver 1000 способен обрабатывать запросы от 4000 пользователей, или от 500 пользователей на процессор. (Эти результаты были достигнуты на многопотоковом сервере Oracle Version 7, работающим в режиме клиент/сервер, причем в качестве фронтальной системы использовался монитор обработки транзакций Tuxedo/T.) Следует отметить, что этот результат был достигнут специалистами компании Sun и Oracle путем очень тщательной настройки ОС Solaris, СУБД Oracle и самого оценочного теста. Возможности этих специалистов по настройке системы, очевидно значительно превосходят возможности большинства пользователей. Более реалистическая верхняя граница числа пользователей на процессор возможно составляет порядка 100-200 пользователей на один процессор 50 МГц SuperSPARC, даже для легких транзакций типа TPC-A. Более крупные приложения естественно приводят к меньшему числу пользователей на процессор.

Работа прикладного пакета Oracle*Financials создает для системы значительно более тяжелую рабочую нагрузку, чем работа теста TPC-A. Это связано с несколькими причинами. Во-первых, по сравнению с одной транзакцией, выполняемой тестом TPC-A, пакет Financials генерирует множество различных транзакций. Во-вторых, после того как данные найдены, сама основная СУБД должна выполнить нетривиальный объем прикладной обработки. В-третьих, пакет Financials не может работать с монитором обработки транзакций. Эксперименты компании Sun с этим пакетом показали, что процессор 50 МГц SuperSPARC может обрабатывать примерно 15 полностью активных пользователей в режиме разделения времени и 40-60 полностью активных пользователей в режиме клиент/сервер, даже с минимальным временем обдумывания.

Таблица 2.3. Примерное число поддерживаемых пользователей на ЦП

Ни операционная система Solaris 2, ни СУБД не масштабируются линейно (то же самое происходит и с конкурирующими операционными системами). Поскольку как Solaris 2, так и версии СУБД под Solaris 2 являются относительно новыми, таблица 2.3 отражает коэффициент масштабирования на уровне 70% (т.е. дублирование процессоров дает 70% увеличение производительности). Ожидается, что эти цифры со временем будут улучшаться по мере дальнейшей настройки как Solaris 2, так и СУБД особенно в направлении достижения лучшей многопроцессорной масштабируемости.

Эти цифры заявлены компанией Sun исключительно для интерактивной пользовательской нагрузки. В действительности рабочие нагрузки, подобные показанным здесь, редко возникают (если вообще возникают) без пакетной обработки. В общем случае для обработки пакетных заданий в конфигурацию системы необходимо включить дополнительный процессор. До сих пор на этот счет доступно очень мало данных. Приведенное здесь эмпирическое правило должно использоваться только в качестве первой оценки.

Дисковые подсистемы ввода/вывода

Как уже было отмечено при обсуждении требований к основной памяти, обращения к диску выполняются примерно в 30000 медленнее, чем к памяти. В результате, лучший способ оптимизации дискового ввода/вывода - вообще его не выполнять! Однако экономически это не оправдано. Таким образом, обеспечение достаточной пропускной способности (емкости доступа) подсистемы ввода/вывода, является решающим фактором для обеспечения высокой устойчивой производительности СУБД. Множество технических соображений приводят к некоторым удивительным результатам.

Соотношение запрос/индекс/диск

Без понимания приложения заказчика, стратегии индексации, принятой администратором базы данных, а также механизмов поиска и хранения СУБД сложно сделать точное утверждение о том, какого типа доступ к диску данная транзакция будет навязывать системе. Особенно трудно количественно определить сложные транзакции, которые имеют место в приложениях третьих фирм, например, в продукте R/3 SAP, который надстроен над Oracle. Однако в отсутствие фирменной информации стоит предположить, что любая транзакция, которая находит небольшое число специально поименованных записей из индексированной таблицы "по индексному ключу" будет представлять собой операцию произвольного доступа к диску. Например, транзакция

select name, salary from employee

were phone-number = "555-1212" or

ssn = "111-111-1111";

почти наверняка будет осуществлять произвольное обращение к диску, если таблица служащих индексируется с помощью phone-number и ssn. Однако, если таблица индексируется только именем и номером служащего, то такая транзакция будет выполняться путем последовательного сканирования таблицы, вполне возможно затрагивая каждую ее запись.

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

Рассмотрим запрос

select part_no, description, num-on-hand from stock

where (part_no > 2000 and part_no < 24000);

Если складская таблица индексируется с помощью part_no (что очень вероятно), этот запрос будет вероятно генерировать последовательное сканирование индексов (а возможно только частичное сканирование, если индексы физически хранятся в некотором способом отсортированном порядке), за которым последует произвольная выборка подходящих строк из таблицы данных. Однако, если по каким-то причинам эта таблица не индексировалась бы с помощью part_no, то запрос почти наверняка приводил бы к полному сканированию таблицы.

Напомним, что любое обновление базы данных связано и с обновлением всех затронутых индексов, а также с выполнением записи в журнал. К сожалению, вся эта техника уходит далеко за рамки данной части курса, требуя основательного понимания работы конкретной используемой СУБД, сложной природы запросов и методов оптимизации запросов. Оценка требований к выполнению дисковых операций оказывается неточной без детальной информации о том, как СУБД хранит данные, даже для показанных здесь простых транзакций. Вычисление количества и типа дисковых обращений для операции соединения пяти таблиц, ограниченной коррелирующим подзапросом был бы сложен даже для авторов приложения!

Замечание. В случаях, когда ожидается, что такие запросы будут определять общую производительностью прикладной системы, следует настаивать на консультациях экспертов. Диапазон ошибок для такого рода запросов часто составляет 1000:1!

Емкость и пропускная способность дисковой памяти

Одной из наиболее общих проблем в СУБД является обеспечение большой емкости дисковой памяти для хранения данных при достаточной пропускной способности дисковой подсистемы. На большинстве серверов при выполнении обращений к диску доминируют операции произвольного доступа. Сегодня на рынке доступны множество дисков, но их производительность при выполнении операций произвольного доступа почти одна и та же:

Таблица 2.4.Временные параметры некоторых дисков

Хотя диск 2.1 Гб имеет впятеро большую емкость, чем диск 424 Мб, он обеспечивает только на 24% лучшую скорость выполнения операций произвольного доступа. В действительности диск 1.05 Гб быстрее, чем диск 2.1 Гб. (Хотя их характеристики очень близки, диск 1.05 Гб имеет дополнительное фирменное обеспечение в своем встроенном контроллере. Главное отличие состоит в том, что контроллер диска 1.05 Гб способен соединяться и разъединяться с шиной SCSI намного быстрее, чем контроллер диска  2.1 Гб). По этим причинам наилучшие результаты почти всегда достигаются при использовании наименьшего по емкости диска, даже когда больший диск имеет превосходные спецификации по всем параметрам. Например, сервер SPARCserver 1000 может оснащаться дисками емкостью 535 Мб, 1.05 Гб и 2.1 Гб. Как видно из таблицы 2.5, для заданного объема дисковой памяти (16 Гбайт), общая пропускная способность дисковой подсистемы существенно выше при использовании дисков 535 Мб (больше чем в три раза).

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

Таблица 2.5. Пропускная способность ввода/вывода для дисковой памяти емкостью 16 Гб

Было бы серьезной ошибкой подбирать для системы дисковые накопители исключительно исходя из требуемой общей емкости дисковой памяти. Хотя эта проблема не нова, со временем она становится все более серьезной, поскольку емкость дисковых накопителей и требования к общей емкости дисковой памяти начинают увеличиваться значительно более быстрыми темпами, чем пропускная способность дисков.

Рекомендации:

• Чтобы добиться наибольшей общей производительности и пропускной способности дисковой подсистемы следует конфигурировать наименьшие по емкости дисковые накопители.

• На одной шине Fast SCSI-2 (10 Мб/с) следует конфигурировать умеренное число (3-5) дисков. Для шины Fast-and-Wide SCSI (20 Мб/с) количество дисков может быть увеличено немного более чем в два раза (8-11 дисков).

• Количество шин SCSI следует выбирать максимально возможным, естественно с учетом других ограничений.

• Для увеличения эффективной пропускной способности дисковой подсистемы следует использовать специальные программные средства типа On-line:DiskSuite и расщепление дисков.

Файловые системы по сравнению с "чистыми" (неструктурированными) дисками

Большинство СУБД позволяют администратору системы выбрать способ размещения файлов СУБД (на "чистых" дисках или в стандартной файловой системе UNIX). Некоторые системы, наиболее известными из которых являются Ingres и Interbase, навязывают использование файловой системы UNIX. Для систем, которые допускают выбор указанных возможностей, приходится оценивать целый ряд разных критериев.

Хранение данных в файловой системе оказывается менее эффективным (отличие составляет по крайней мере 10%), поскольку при выполнении каждого обращения к диску со стороны СУБД в работу включается дополнительный слой системного ПО. Поскольку в больших СУБД часто одним из ограничивающих ресурсов является мощность процессора, использование "чистых" разделов (raw partition) улучшает производительность системы при пиковой нагрузке. Только по этой причине большинство администраторов баз данных обычно предпочитают хранение данных на "чистых" разделах дисков. Если ожидается, что система достигнет своих пределов производительности, особенно в части использования мощности ЦП, то это может быть наиболее подходящий выбор. Однако следует отметить, что эффективность процессора в действительности становится под вопрос только под пиковой нагрузкой. Большинство же систем испытывают эти пиковые нагрузки только в очень редких случаях.

Хранение данных в файловой системе имеет также определенную цену в терминах потери емкости памяти. Файловая система UNIX потребляет примерно 10% от форматированной емкости дисков для метаданных о файлах и файловой системе. Более того, файловая система резервирует 10% оставшегося пространства, чтобы обеспечить быстрый поиск свободного пространства в случае расширения файлов (этот дополнительный объем памяти в принципе может быть использован, но за счет потенциально значительных дополнительных задержек, которые возникнут при открывании или расширении файлов файловой системы). Если СУБД работает с данными через файловую систему, то по сравнению с "чистым" диском емкость дисковой памяти в целом уменьшается на 19%.

Если хранение данных в файловой системе обходится дороже как с точки зрения потребления мощности процессора, так и с точки зрения потерь емкости памяти, возникает вопрос: "А зачем все это нужно?". Имеется несколько важных причин, по которым в СУБД используется хранение данных в файловой системе. Большинство из них связано с обеспечением гибкости или относятся к разряду более знакомой для пользователя технологии.

Во-первых, и что возможно наиболее важно, использование файловой системы позволяет работать с памятью с помощью стандартных утилит UNIX. Например, стандартные утилиты UNIX ufsdump и ufsrestore могут использоваться для того, чтобы производить надежное резервное копирование и восстановление памяти СУБД. Для этого могут также использоваться не связанные с операционной системой инструментальные средства резервного копирования, подобные Online:Backup 2.0 компании Sun. Кроме того, гораздо проще осуществлять манипулирование отдельными частями базы данных. Например, можно осуществлять прямое перемещение таблицы с одного диска на другой, даже если используются диски разного размера и типа. Поскольку каждый из поставщиков СУБД предлагает свои собственные внутренние утилиты резервного копирования и восстановления, все они различны. Более того, некоторые из них выполняются настолько медленно, что заказчики часто прибегают к использованию копирования физических томов (т.е. используют команду dd(1)) со всеми присущими такому копированию сложностями. Хранение данных в файловой системе позволяет выполнять единообразные, надежные процедуры для того, чтобы работать через систему и сеть. При этом, если необходимо, могут также использоваться инструментальные средства поставщиков СУБД.

При некоторых обстоятельствах операции через файловую систему дают возможность оптимизации, которую сама СУБД не может реализовать. В частности, файловая система UNIX пытается кластеризовать данные в более крупные физические единицы, чем большинство СУБД. Поскольку дисковое пространство для таблиц часто заранее распределено, файловой системе обычно удается агрегатировать данные в блоки объемом по 56 Кб, в то время как менеджеры памяти СУБД обычно оперируют только страницами размером в 2 (или иногда 8) Кб. Последовательное сканирование таблиц или индексов, хранящихся таким образом часто может оказаться более эффективным, чем эквивалентных таблиц, хранящихся более традиционным способом. Если в операциях системы доминирует последовательное сканирование (или операции соединения (joins), которые часто подразумевают последовательное сканирование), хранение данных в файловой системе обеспечивает более высокую производительность.

Рекомендации:

• Для обеспечения максимальной пиковой производительности следует конфигурировать "чистые" диски.

• При размещении таблицы СУБД в файловой системе UNIX следует добавить 19% дополнительного дискового пространства на накладные расходы файловой системы.

• Для обеспечения максимальной гибкости можно размещать таблицы СУБД в файловых системах.

• Если СУБД хранит таблицы в файловой системе UNIX следует сконфигурировть 15% дополнительной памяти (или соответственно более маленький кэш разделяемых данных).

Метаданные СУБД

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

Если отсутствует более точная информация, то обычно разумно было бы предусмотреть примерно удвоенный объем дискового пространства по сравнению с объемом "чистых" данных. Это обеспечивает некоторую гибкость для создания индексов и т.п., и в итоге позволяет улучшить производительности приложения. Хотя коэффициент 2 на первый взгляд кажется чрезмерным, следует, например, иметь в виду, что индексация, навязываемая предложенным тестом TPC-D потребляет более 400 Мб. При этом объем "чистых" данных составляет примерно 650 Мб. При использовании устанавливаемых по умолчанию параметров памяти СУБД Oracle, объем "чистых" данных, необходимых для реализации теста TPC-C, увеличивается на 30% при хранении их в базе данных Oracle даже без индексации. Поэтому можно легко потребовать для системы даже гораздо больше, чем 100% дополнительного пространства.

Рекомендации:

• Объем дискового пространства базы данных должен по крайней мере на 50% превышать требования по объему "чистых" данных (к этому необходимо добавить накладные расходы файловой системы, если таковая применяется). Более безопасная цифра - 100%.

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

Распределение данных

Другим фактором, влияющим на конфигурацию подсистемы ввода/вывода, является предполагаемое распределение данных по дискам. Даже минимальная по объему система должна иметь по крайней мере четыре диска: один для операционной системы и области подкачки (swap), один для данных, один для журнала и один для индексов. Конфликты по этим ресурсам в системе с ограничениями ввода/вывода являются самым большим отдельным классом проблем обеспечения производительности в среде, в которой приложение в определенной степени было настроено (т.е. в наиболее продуктивных средах). Более крупные системы должны учитывать даже большее количество переменных, такие как зеркалирование дисков, расщепление дисков и перекрытие ресурсов. Вообще говоря, наиболее продуктивным и достаточно эффективным по стоимости способом распределения данных является обеспечение всех основных логических сущностей отдельным набором дисков.

Хотя технически возможно объединить по несколько логических функций на одних и тех же (физических или логических) дисках, для подсистемы ввода/вывода это оказывается очень разрушительным и почти всегда приводит к неудовлетворительной производительности. Например, рассмотрим базу данных, которая состоит из таблицы данных размером 1.5 Гбайт и индексов объемом 400 Мбайт, и которая требует 40 Мбайт для размещения журнального файла. Соблазнительно просуммировать эти объемы вместе и обнаружить, что вся эта информация может поместиться на одном диске емкостью 2.1 Гбайт. Если реализовать такую конфигурацию системы, то при выполнении приложением практически любого обновления базы данных, каретка диска все время будет сновать челноком по диску для каждой транзакции. В частности, процесс формирования журнала, который должен писаться синхронно и медленно, в действительности будет выполняться в режиме произвольного доступа, а не в режиме последовательного доступа к диску. Уже только это одно будет существенно задерживать каждую транзакцию обновления базы данных.

Кроме того, выполнение запросов, выбирающих записи из таблицы данных путем последовательного сканирования индекса, будет связано с сильно увеличенным временем ожидания ввода/вывода. Обычно сканирование индекса выполняется последовательно, но в данном случае каретка диска должна перемещаться для поиска каждой записи данных между выборками индексов. В результате происходит произвольный доступ к индексу, который предполагался последовательным! (В действительности индекс мог специально создаваться с целью последовательного сканирования). Если таблица данных, индекс и журнал находятся на отдельных дисках, то произвольный доступ к диску осуществляется только при выборке данных из таблицы и результирующая производительность увеличивается вдвое.

Последним пунктом обсуждения возможности объединения разных функций на одних и тех же физических ресурсах является то, что подобное объединение часто создает ситуации, в которых максимизируются времена подвода головок на диске. Хотя время позиционирования в спецификациях дисковых накопителей обычно приводится как одно число, в действительности длительность позиционирования сильно зависит от необходимого конкретного перемещения головок. Приводимое в спецификациях время позиционирования представляет собой сумму времен всех возможных позиционирований головок, деленное на количество возможных позиционирований. Это не то время, которое затрачивается при выполнении "типичного" позиционирования. Сама физика процесса перемещения дисковой каретки определяет, что позиционирование на короткое расстояние занимает гораздо меньше времени, чем на длинное. Позиционирование на смежный цилиндр занимает всего несколько миллисекунд, в то время как позиционирование на полный ход каретки длится значительно больше времени, чем приводимое в спецификациях среднее время позиционирования. Например, для диска 2.1 Гб позиционирование головки на соседний цилиндр обычно занимает 1.7 мс, но длится 23 мс для полного хода каретки (в 13 раз дольше). Поэтому длительное позиционирование головок, возникающее при последовательности обращений к двум разным частям диска, необходимо по возможности исключать.

Рекомендации:

• Отдельные логические функции СУБД следует реализовывать на отдельных выделенных дисковых ресурсах.

• Необходимо планировать размещение данных на дисках для минимизации количества и длительности позиционирования головок.

Использование ресурсов ввода/вывода

При разработке подсистемы ввода/вывода должно быть уделено внимание не только максимальной емкости ее компонентов, но также уровню использования (загруженности) каждого ресурса. Большинство параметров, используемых для описания емкости ресурсов, так или иначе связаны с пропускной способностью. Например, шина SCSI характеризуется пропускной способностью в 10 Мбайт/с. Это скорость пересылки битов по шине. Такой параметр не дает информации о том, насколько занята сама шина и, следовательно, не дает также информации о том, сколько времени будет потрачено на обслуживание данного запроса. Приводить в качестве параметра ресурса рейтинг максимальной пропускной способности - все равно, что говорить, что предел скорости автомагистрали равен 130 км в час: если въезды и съезды с нее так перегружены, что это занимает длительное время, то общая скорость вероятно будет намного ниже установленного предела.

Точно такие же принципы применимы к различным периферийным устройствам и периферийным шинам. В частности, это справедливо и для шин SCSI. Экспериментальные результаты показывают, что если должна поддерживаться пиковая производительность, то степень загруженности шины SCSI должна поддерживаться на уровне 40%. Аналогичным образом, степень загрузки дисков должна поддерживаться на уровне 60%. Диски могут выдерживать значительно большую степень загрузки чем шина SCSI, поскольку во встроенных дисковых контроллерах имеется интеллект и средства буферизации. Это позволяет координировать работу буферов дорожек, каретки диска и очереди запросов такими способами, которые не возможны на достаточно примитивных главных адаптерах шины SCSI.

Обычно невозможно оценить, какова будет средняя степень загрузки дисков или шины SCSI до тех пор, пока система не начнет работать. В результате, достаточно приемлемой оказывается такая конфигурация, которая позволяет распределить часто используемые данные и индексы по стольким дискам и шинам SCSI, сколько позволяют бюджет и технические ограничения. Для данных, доступ к которым происходит не очень часто, например, только во время ночной пакетной обработки (или других полуархивных данных подобных транзакциям годовой давности), можно рекомендовать как можно более плотную упаковку на накопителях.

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

В контексте СУБД имеется по крайней мере два механизма для распределения данных по дисковым накопителям. Для эффективного распределения доступа к данным все известные СУБД имеют возможность осуществлять конкатенацию нескольких дисковых накопителей или файлов UNIX. (В СУБД Ingres, например, реализовано истинное расщепление дисков, ограниченное стандартным размером чередования 16 Кбайт). Похожие возможности (помимо горячего резервирования и расщепления дисков) предлагают и специальные программные средства типа Online:DiskSuite. Если работа с таблицей ограничивается возможностями подсистемы ввода/вывода, следует исследовать запросы, которые вызывают ввод/вывод. Если эти запросы реализуют произвольный доступ к дискам, например, если многие пользователи независимо запрашивают индивидуальные записи, то имеющиеся возможности конкатенации дисков в СУБД полностью адекватны распределению нагрузки доступа по множеству дисков (при достаточно полном заполнении пространства таблицы). Если обращения по своей природе последовательны, например, если один или несколько пользователей должны просматривать каждую строку таблицы, то больше подходит механизм расщепления дисков.

Основное преимущество использования расщепления с помощью средств, подобных  Online:DiskSuite, заключается в том, что задача распределения обращений к данным становится гораздо более простой для администратора базы данных. При действительном расщеплении эта задача тривиальна и почти всегда дает оптимальные результаты. Часто это не тот случай, когда логически разделение данных по пространствам таблицы использует внутренние механизмы СУБД. Задача заключается в том, чтобы распределить тяжело используемые таблицы по отдельным дисковым ресурсам, однако часто невозможно принять решение относительно конфликтующих комбинаций запросов при обращениях к этим таблицам, приводящих к неровной нагрузке. При использовании  DiskSuite степень загруженности дисков сама будет стремиться к естественному уровню.

Обычно СУБД делят таблицу на несколько относительно больших сегментов и размещают данные равномерно по этим сегментам. Главное отличие между конкатенацией СУБД и функцией расщепления Online:DiskSuite заключается в размещении смежных данных. Когда диски конкатенируются друг с другом, последовательное сканирование представляет собой тяжелую нагрузку для каждого из дисков, но эта нагрузка носит последовательный характер (только один диск участвует в обслуживании запроса). Истинное расщепление дисков, реализованное в Online:DiskSuite, осуществляет деление данных по гораздо более мелким границам, позволяя тем самым всем дискам участвовать в обслуживании даже сравнительно небольшого запроса. Как результат, при использовании расщепления загрузка дисков при выполнении последовательного доступа существенно уменьшается. К архивным и журнальным файлам всегда осуществляется последовательный доступ и они являются хорошими кандидатами для расщепления, если реализация обращений к таким файлам ограничивает общую производительность системы.

По мере продолжения роста размеров и важности баз данных, процедуры резервного копирования, которые выполняются с блокировкой доступа к СУБД, становятся практически неприемлемыми. При реализации резервного копирования в оперативном режиме (режиме online) могут возникнуть достаточно сложные вопросы по конфигурированию соответствующих средств, поскольку резервное копирование больших томов данных, находящихся в базах данных, приводит к очень интенсивной работе подсистемы ввода/вывода. Резервное копирование в оперативном режиме часто вызывает очень высокий уровень загрузки дисков и шины SCSI, что приводит к низкой производительности приложений. Следует уделять особое внимание конфигурациям всех устройств, вовлеченных в процессы резервного копирования.

Рекомендации:

• После начальной инсталляции необходимо наблюдать за работой системы и переразмещать данные до тех пор, пока каждый дисковый накопитель не будет загружен менее, чем на 60%.

• Для распределения последовательных дисковых обращений по множеству дисков рекомендуется использовать программные продукты типа Online:DiskSuite.

• Когда типовой доступ к диску носит характер произвольного обращения, для более равномерного распределения обращений к данным и уменьшения степени загрузки дисков следует использовать встроенную в СУБД функцию кокатенации.

• Особое внимание следует уделять влиянию резервного копирования в режиме online на работу системы, особенно на загрузку шины SCSI.

Сетевая подсистема ввода/вывода

Соображения по использованию режима клиент/сервер

Если СУБД работает в режиме клиент/сервер, то сеть или сети, соединяющие клиентов с сервером должны быть адекватно оборудованы. К счастью, большинство клиентов работают с вполне определенными фрагментами данных: индивидуальными счетами, единицами хранящихся на складе изделий, историей индивидуальных счетов и т.п. При этих обстоятельствах скорость сети, соединяющей клиентов и серверы редко оказывается проблемой. Отдельной сети Ethernet или Token Ring обычно достаточно для обслуживания 100-200 клиентов. На одном из тестов Sun конфигурация клиент/сервер, поддерживающая более 250 пользователей Oracle*Financial, генерировала трафик примерно 200 Кбайт/с между фронтальной системой и сервером базы данных. По очевидным причинам стоит более плотно наблюдать за загрузкой сети, особенно когда число клиентов превышает примерно 20 на один сегмент Ethernet. Сети Token Ring могут поддерживать несколько большую нагрузку, чем сети Ethernet, благодаря своим превосходным характеристикам по устойчивости к деградации под нагрузкой.

Даже если с пропускной способностью сети не возникает никаких вопросов, проблемы задержки часто приводят к тому, что более удобной и полезной оказывается установка отдельной, выделенной сети между фронтальной системой и сервером СУБД. В существующих в настоящее время конфигурациях серверов почти всегда используется большое количество главных адаптеров шины SCSI; поскольку как правило эти адаптеры спарены с портами Ethernet, обеспечение выделенного канала Ethernet между клиентом и сервером выполняется простым их подключением к дешевому хабу с помощью кабельных витых пар. Стоимость 4-портового хаба не превышает $250, поэтому причины, по которым не стоило бы обеспечить такое выделенное соединение, практически отсутствуют.

Большие объекты данных

Однако в ряде случаев возможностей сетей Ethernet или Token Ring может оказаться недостаточно. Чаще всего это случается, когда данные хранятся в базе в виде очень больших массивов. Например, в медицинских базах данных часто хранятся образы рентгеновских снимков, поскольку они могут быть легко быть объединены с другими данными истории болезни пациента; эти образы рентгеновских снимков часто бывают размером в 3-5 Мбайт. Другими примерами приложений с интенсивным использованием данных являются системы хранения/выборки документов, САПР в области механики и системы мультимедиа. В этих случаях наиболее подходящей сетевой средой является FDDI, хотя в сравнительно ближайшем будущем она может быть будет заменена на ATM или  100 Мбит Ethernet.

Для систем, требующих большей пропускной способности сети, чем обеспечивают  Ethernet или Token Ring, по существу до конца 1994 года FDDI была единственным выбором. Хотя концентраторы FDDI имеют значительно большую стоимость по сравнению с хабами Ethernet, установка выделенной сети между фронтальной системой и сервером СУБД оказывается достаточно простой и недорогой. Как определено в стандарте FDDI, минимальная сеть FDDI состоит только из двух систем, соединенных между собой с помощью единственного кабеля. Никаких концентраторов не требуется, а цены на некоторые интерфейсы FDDI в настоящее время упали до уровня менее $1500.

Конфигурация клиент/сервер и региональные сети

В последнее время резко увеличилось число приложений, в которых фронтальные системы и серверы СУБД могут или должны размещаться в географически разнесенных местах. Такие системы должны соединяться между собой с помощью глобальных сетей. Обычно средой передачи данных для таких сетей являются арендованные линии с синхронными последовательными интерфейсами. Эти линии обычно работают со скоростями 56-64 Кбит/с, 1.5-2.0 Мбит/с и 45 Мбит/с. Хотя скорость передачи данных в такой среде значительно ниже, чем обычные скорости локальных сетей, подобных Ethernet, природа последовательных линий такова, что они могут поддерживать очень высокий уровень загрузки. Линия T1 предлагает пропускную способность 1.544 Мб/с (2.048 Мбит/с за пределами США). По сравнению с 3.5 Мбит/с, обеспечиваемых Ethernet в обычном окружении, линия T1 предлагает пропускную способность, которая количественно практически не отличается от Ethernet. Неполные линии T3 часто доступны со скоростями 10-20 Мбит/с, очевидно соперничая с сетями Ethernet и Token Ring. В ряде случаев можно найти приложения, которые могут работать успешно в конфигурации клиент/сервер даже через сеть со скоростью 56 Кбит/с.

Для традиционных бизнес-приложений трафик конфигурации клиент/сервер обычно содержит сравнительно низкий объем данных, пересылаемых между фронтальной системой и сервером СУБД, и для них более низкая пропускная способность сети может оказаться достаточной. В большинстве случаев задержка сети не является большой проблемой, однако если глобальная сеть имеет особенно большую протяженность, или если сама среда передачи данных имеет очень большую задержку (например, спутниковые каналы связи), приложение должно быть протестировано для определения его чувствительности к задержкам пакетов.

Для сокращения трафика клиент/сервер до абсолютного минимума могут использоваться мониторы обработки транзакций.

Трафик символьного терминала

Общей ошибкой пользователей является представление о том, что сетевой трафик, связанный с терминальными серверами, может перегрузить Ethernet. Это неправильно. Рассмотрим, например, 64-портовый сетевой терминальный сервер, который может управлять каждым портом, работающим со скоростью 38400 бод, или 38400 символов в секунду. (В каждом байте данных содержится 8 бит информации, но рейтинг бод включает биты старта и стопа). Если каждый порт работает на полной скорости 38400 бод, то всего за одну секунду по сети будет пересылаться 2457600 байт данных (или примерно 1.9 Мбит, т.е. около 20% максимальной загрузки Ethernet) с главной системы в терминальный сервер для дальнейшего распределения. Конечно имеются некоторые накладные расходы (дополнительные байты TCP/IP), связанные с этим уровнем трафика, но они составляют примерно 50 байт на пакет, т.е. примерно 4% для этого уровня трафика. Это сценарий наихудшего случая, например, когда на полной скорости работают 64 принтера. Типичный же уровень трафика намного ниже: один 2000-символьный экран может отображаться один раз в минуту. При этих условиях 64-портовый терминальный сервер обрабатывает примерно 35 байт в секунду на один порт или всего примерно 2 Кбайт/с.

Операции по вводу символов с клавиатуры терминала можно вообще не рассматривать, поскольку даже самая быстрая машинистка печатает только 20 символов в секунду (более типичный случай 1.0 - 1.5 символов в секунду). Даже если операции ввода обрабатываются в режиме cbreak, наибольшая нагрузка, которая будет генерироваться всеми пользователями, может составлять 1300 символов в секунду (по 20 символов в секунду на каждый порт при 64 портах). После учета максимальных накладных расходов TCP/IP это дает общий поток в 80 Кбайт/с . Типичные нагрузки (64 порта по 1.5 символа в секунду) будут составлять порядка 15 Кбайт/с с учетом накладных расходов.

Заключительные рекомендации по конфигурированию сетевого ввода/вывода

• Для конфигураций клиент/сервер, где клиенты работают на удаленных ПК или рабочих станциях, следует конфигурировать по 20-50 клиентов на одну сеть Ethernet. Количество клиентов в одной сети 16 Мбит/с Token Ring может достигать 100 благодаря прекрасной устойчивости к деградации под нагрузкой.

• Если фронтальная система обслуживает большое количество клиентов, то между фронтальной системой и сервером СУБД следует предусмотреть специальную выделенную сеть. При этом если приходится манипулировать очень большими объектами данных (более 500 Кбайт на объект), то вместо сетей Ethernet или Token Ring следует применять FDDI.

• Фронтальная система и сервер СУБД могут объединяться с помощью глобальных сетей, обеспечивающих "достаточную" полосу пропускания. В идеале это предполагает по крайней мере использование неполной линии T1. Такие приложения должны быть относительно малочувствительны к задержке сети.

• При конфигурировании систем клиент/сервер с использованием глобальных сетей следует исследовать возможность применения мониторов обработки транзакций для снижения трафика клиент/сервер до минимума.

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

PrestoServe/NVSIMM

По определению семантики оператора SQL COMMIT_WORK любая СУБД должна гарантировать, что все обновления базы данных должны направляться и фиксироваться в стабильной памяти (т.е. любой памяти, которая обеспечивает устойчивое хранение данных даже в условиях сбоев системы или отказов питания). Чтобы СУБД могла дать такую гарантию, она должна выдавать для выполнения по крайней мере некоторые из своих операций записи синхронно. Во время выполнения таких записей операционная система блокируется и не возвращает управление вызвавшей программе до тех пор, пока данные не будут зафиксированы в стабильной памяти. Хотя эта стратегия очень надежна, вместе с тем она приводит к существенному замедлению операций, поскольку при выполнении синхронных записей обязательно требуется, чтобы данные были записаны непосредственно на дорожку диска. Синхронная запись на "чистый" диск занимает примерно 20 мс, а синхронная запись в файловую систему может занять в несколько раз больше времени (если должны быть выполнены обновления в косвенные блоки или блоки с двойной косвенностью).

Обычно СУБД осуществляют синхронную запись только в свои журналы - в случае отказа системы сама база данных может быть реконструирована из синхронно записанного журнала. Иногда система в целом становится узким местом в процессе заполнения журнала. Обычно это случается в среде тяжелой обработки транзакций, которая выполняет многочисленные обновления базы данных (приложения, выполняющие только чтение базы данных, подобные системам поддержки принятия решений, осуществляют немного записей в журнал). Этот эффект еще более усиливается при использовании для журнальных дисков зеркальных пар. В этих случаях для ускорения процесса журнализации часто полезно использовать PrestoServe или NVSIMM. Фиксация записей в немеханических NVRAM, устанавливаемых на PrestoServe или в NVSIMM может существенно расшить узкое горло в некоторых системах.

Рекомендации:

• Если приложение связано с ведением журнала или если приложение жестко ориентировано на проведение обновлений, следует включить в конфигурацию системы NVSIMM или PrestoServe.

• Для гарантии от потери данных следует размещать журналы СУБД на зеркальных дисковых парах.

Обеспечение резервного копирования

Поскольку обычно базы данных бывают очень большими и в них хранится исключительно важная информация, правильная организация резервного копирования данных является очень важным вопросом. Объем вовлеченных в этот процесс данных обычно огромен, особенно по отношению к размеру и обычной скорости устройств резервного копирования. Просто непрактично осуществлять дамп базы данных объемом 20 Гбайт на 4 мм магнитную ленту, работающую со скоростью 500 Кбайт/с: это займет примерно 12 часов. В этой цифре не учтены даже такие важные для работы системы соображения, как обеспечение согласованного состояния базы данных и готовность системы.

Когда необходимо выполнять резервное копирование?

Составить расписание для резервного копирования системы, которая используется главным образом в течение нормального рабочего времени, обычно сравнительно просто. Для выполнения процедур резервного копирования после завершения рабочего дня часто используются скрипты. В некоторых организациях эти процедуры выполняются автоматически даже без привлечения обслуживающего персонала, в других в неурочное время используют операторов. Для выполнения автоматического резервного копирования без привлечения обслуживающего персонала требуется возможность его проведения в рабочем режиме (режиме online).

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

Резервное копирование в режиме online

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

При выполнении резервного копирования базы данных предполагается, что она находится в согласованном состоянии, т.е. все зафиксированные обновления базы данных не только занесены в журнал, но и записаны также в таблицы базы данных. При реализации резервного копирования в режиме online возникает проблема: чтобы резервные копии оказались согласованными, после того как достигнута точка согласованного состояния базы данных и начинается резервное копирование, все обновления базы данных должны выполняться без обновления таблиц самой базы до тех пор, пока не завершится ее полное копирование. Большинство основных СУБД обеспечивают возможность резервного копирования в режиме online.

Продолжительность резервного копирования

Продолжительность процедур резервного копирования возможно является наиболее важным вопросом для организаций с большими базами данных (объемом более 10 Гбайт), и выбор методики резервного копирования может определяться именно этим. Резервное копирование небольших баз данных может легко осуществляться при наличии всего одного накопителя на магнитной ленте Exabyte или DAT. Хотя выпускаемые в настоящее время накопители на МЛ позволяют копировать данные со скоростью примерно 1.25 Гбайт в час, для больших баз данных это очевидно неприемлемо. Для увеличения пропускной способности несколько устройств могут работать параллельно, хотя конфликты по ресурсам делают этот способ недостаточно эффективным при использовании одновременно более трех-четырех НМЛ.

Некоторые НМЛ на 8 мм ленте с аппаратной компрессией способны обеспечивать скорость до 3 Гбайт/час, т.е. более чем вдвое превышают скорость стандартных устройств. Некоторые из этих устройств имеют емкость до 25 Гбайт, но более типичной является емкость 8-10 Гбайт. Совместимые с IBM 3480 устройства, например, Fujitsu Model 2480, могут обеспечивать скорость около 10 Гбайт в час, но ограниченный объем носителя (200-400 Мбайт до компрессии) означает, что для обеспечения эффективности они должны устанавливаться в механических стекерах. Некоторые относительно новые устройства используют носитель информации в формате VHS и предлагают исключительно высокую пропускную способность и емкость. В сообщении об одном из таких устройств (от Metrum) указана скорость передачи в установившемся режиме почти 15 Мбайт/с при подключении с помощью выделенных каналов fast/wide SCSI-2. Емкость этого устройства составляет 14 Гбайт на одну ленту без компрессии.

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

Использование зеркалирования дисков для облегчения резервного копирования

Простым, но эффективным способом сокращения времени резервного копирования является выполнение копирования на отдельный зеркальный диск. ПО Online:DiskSuite предлагает зеркалирование с очень небольшими накладными системными расходами. Если зеркальная копия сделана непосредственно после контрольной точки, или после того как база данных выключена, она действительно становится онлайновой дисковой резервной копией, которая сама может быть скопирована в любое удобное время. Можно даже выполнить рестарт базы данных, чтобы продолжить нормальную обработку, хотя с меньшей избыточностью. Если доступно достаточное количество дисковых накопителей, то может быть использован и второй набор зеркальных дисков, что позволяет сохранить полное зеркалирование даже, когда один набор зеркальных дисков отключается (во время нормальных операций диски будут зеркалироваться по трем направлениям). В этом случае резервное копирование в режиме online может продолжаться после копирования на ленту, что обеспечивает в случае необходимости очень быстрое восстановление. Этот дополнительный набор зеркальных дисков мог бы быть заново подключен перед следующей контрольной точкой, обеспечив достаточно времени (примерно 30 минут), которое позволит этому набору зеркальных дисков синхронизоваться с зеркальными дисками, работавшими в режиме online.

Частота резервного копирования

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

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

Утилиты резервного копирования

При использовании "чистых" дисковых разделов, выбор прост: в действительности единственными командами UNIX, работающими с "чистыми" разделами, являются dd и  compress. При хранении таблиц СУБД в файловых системах USF можно выбрать, например, команды tar, cpio и usfdump. Большинство пользователей предпочитают usfdump(1) (dump(1) для Solaris 1.X), или ее эквивалент в Online Backup (hsmdump для Solaris 2.X). Большинство СУБД имеют утилиты для выделения из базы данных "чистых" данных и их копирования на внешний носитель, но эти операции обычно выполняются намного медленнее, чем простое копирование "чистых" разделов диска.

Отслеживание и проверка резервных копий

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

26 защита сервера от несанкционированного доступа

Отдельное место при обсуждении протокола занимают вопросы, связанные с обеспечением защиты ресурсов сервера от несанкционированного доступа. Как было отмечено в предыдущих разделах, первоначально разработка защищенных способов обмена данными в системе World Wide Web не предполагалась. Однако быстрое развитие популярности системы привело к тому, что многие коммерческие организации стали устанавливать серверы HTTP на свои машины. Кроме этого, конфиденциальной информации много и в научно-исследовательских государственных организациях. Таким образом, возникла необходимость в разработке механизмов защиты информации для системы WWW. Проблема защиты информации на Internet - это отдельная большая тема. В данном разделе мы рассмотрим только обеспечение безопасности при использовании серверов HTTP. При обсуждении этой проблемы полезно вспомнить схему WWW-технологии (рисунок 3.26). Из этой схемы видно, что в этой технологии имеется как минимум две потенциальные "дыры" . Первая связана с чтением защищенных текстовых файлов. Для решения этой задачи имеется достаточно много традиционных механизмов, встроенных в операционные системы. Проблема возникает, если администратор системы решит использовать для размещения WWW-файлов и FTP-архива одно и тоже дисковое пространство. В этом случае защищенные WWW-файлы окажутся доступными для "анонимного" FTP-доступа. Многие серверы разрешают создавать в дереве поддерживаемых ими документов "домашние" страницы пользователей с помощью методов POST и GET. Это значит, что пользователи могут изменять информацию на компьютере сервера. Данные, вводимые пользователем, передаются как тело ресурса при методе POST через стандартный ввод, а методе GET через переменные окружения. Естественно, что разрешение создания файлов на сервере протокола HTTP создает потенциальную опасность доступа к защищенной информации лиц, не имеющих права доступа к ней. Решается эта проблема путем создания специальных файлов прав пользователей сервера WWW. Рис. 3.28. Схема управления ресурсов сервером HTTP Вторая возможность проникновения в компьютерную систему через сервер WWW связана с CGI-скриптами. CGI-скрипт - это программа, которую сервер HTTP может запускать для реализации механизмов, не предусмотренных в протоколе. Многие достаточно мощные информационные механизмы WWW реализованы посредством CGI-скриптов. К ним относятся: программы поиска по ключевым словам, программы реализации графических гипертекстовых ссылок - imagemap, программы сопряжения с системами управления базами данных и т.п. Естественно, что при этом появляется возможность получить доступ к системным ресурсам. Обычно внешняя программа запускается с идентификатором пользователя, отличным от идентификатора сервера. Данный идентификатор указывается при конфигурировании сервера. Наиболее безопасным здесь является идентификатор пользователя nobody (65534). Основная опасность скриптов заключена в том, что данные в скрипт посылаются программой-клиентом. Для того, чтобы в качестве параметров не передавали "подозрительных" данных, многие серверы производят проверку параметров на наличие допустимых символов. Особенно опасны скрипты для тех, кто использует сервер на персональном компьютере с MS-Windows 3.1. В этом случае файловая система практически не защищена. Одной из характерных для скриптов проблем является размер входных данных. Многие "умные" серверы обрезают слишком большие входные потоки и тем самым защищают скрипты от "поломки". Кроме перечисленных выше опасностей, порождаемых природой сети и системы WWW, существует еще одна, связанная с такой экзотикой, как мобильные коды. Мобильный код - это программа, которая может передаваться по сети для выполнения ее клиентом. Код встраивается в WWW-страницу при помощи тага <APP ...> - application. Например, Sun выпустила WWW-клиента HotJava, который позволяет интерпретировать язык Java. Существуют клиенты и для других языков, Safe-Tcl для Tcl, например. Главное назначение таких средств - реализация мультимедийных страниц и реализация работы в rеal-time. Опасность применения такого сорта страниц очевидна, так как повторяет способ распространения различного сорта вирусов. Однако пока речи о защите от такого сорта "взломов" не идет, видимо в силу довольно ограниченного применения данной возможности в сети. Практически любой сервер имеет механизм назначения паролей и прав доступа для различных пользователей, который базируется на схеме идентификации протокола HTTP 1.0. Данная схема предполагает, что программа-клиент посылает серверу идентификатор пользователя и пароль. Понятно, что такой механизм не обеспечивает защиты передаваемой по сети информации, и она может стать легкой добычей злоумышленников. Для того, чтобы этого не происходило, в рамках WWW ведется разработка других схем защиты. Они строятся на двух широко известных принципах: контроль доступа по IP-адресам и шифрация. Первый принцип реализован в программе типа "стена" (Firewall). Сервер разрешает обращаться к себе только с определенных IP-адресов и выполнять только определенные операции. Слабое место такого подхода с точки зрения WWW заключается в том, что обратиться могут через сервер-посредник, которому разрешен доступ к ресурсам защищенного первичного сервера. Поэтому применяют шифрование паролей и идентификаторов по аналогии с системой "Керберос". На принципе шифрования построен новый протокол SHTTP, который реализован в серверах Netsite (последние версии), Apachie и в новых серверах CERN и NCSA. Однако реально широкого применения это программное обеспечение еще не нашло и находится в стадии развития, а потому содержит достаточно большое количество ошибок. Завершая обсуждение протокола HTTP и способов его реализации, нужно отметить, что в качестве широко доступного информационного ресурса WWW уже состоялась, следующий шаг - серьезные коммерческие применения. Но для этого необходимо еще внедрить в практику защищенные протоколы обмена, базирующиеся на HTTP. В последнее время появилось много новых программ, реализующих протокол HTTP. Это серверы и клиенты, написанные как для новых компьютерных платформ, так и для возможностей SHTTP. Реальную возможность попробовать свои силы в разработке различных WWW-приложений имеют и отечественные программисты.

27 сетевое программное обеспечение

Сетевое программное обеспечение делится на три категории:

1. ПО управления сетевой платой;

2. ПО выполняющее правила (или протокол) общения в сети;

3. ПО сетевой операционной системы.

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

ЛВС бывают двух основных типов: равноправные (или одноранговые) и с выделенным сервером. В равноправной локальной сети все узлы равноправны: любая РСТ может выступать по отношению к другой как клиент или как сервер. В сети с выделенным сервером все клиенты общаются с центральным сервером.

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

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

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

Наиболее популярным сетевым ПО с выделенным сервером является ОС Novell NetWare, используемая, по некоторым оценкам, в 70% локальных сетей. К числу других широко известных СОС этого класса относятся Banyan Vines, IBM LAN Server для OC/2, DEC Pathworks для VAX и Windows NT, а также Microsoft Windows NT Server.

Сетевые операционные системы помогают осуществлять основные работы, проводимые в сети:

• файловая поддержка (создание, поиск файлов);

• коммуникации (взаимообмен данными);

• услуги поддержки оборудования.

Сетевые операционные системы могут базироваться на операционных системах MS DOS, OS/2, Unix, Macintosh, Windows или на своих собственных операционных системах. Но вне зависимости от операционной системы, на которой базируется сетевая операционная система, они предоставляют средства обеспечения безопасности данных путем контроля прав доступа пользователей к рабочим программам, массивам данным и ресурсам сети.

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

Существуют, однако, специальные программы, работающие в сети с централизованным управлением и позволяющие передавать данные непосредственно от одной рабочей станции к другой, минуя файл-сервер, например NetLink. После ее запуска на двух рабочих станциях можно передавать файлы с диска одной станции на диск другой, аналогично тому, как копируются файлы из одного каталога в другой при помощи программы Norton Commander. На рабочих станциях должно быть установлено специальное программное обеспечение, часто называемое сетевой оболочкой. Это обеспечение работает в среде той ОС, которая используется на данной рабочей станции, — DOS, Windows, OS/2 и т. д.

Файл-серверы могут быть выделенными или невыделенными

Существуют различные сетевые операционные ситемы, ориентированные на сети с централизованным управлением. Самые известные из них — Windows NT, Novell NetWare, Microsoft Lan Manager (на базе OS/2), a также выполненная на базе UNIX System V сетевая OS VINES.

Одноранговые сети не содержат в своем составе выделенных серверов. Функции управления сетью передаются по очереди от одной рабочей станции к другой. Как правило, рабочие станции имеют доступ к дискам (и принтерам) других рабочих станций. Такой подход облегчает совместную работу групп пользователей, но в целом производительность сети может понизиться.

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

Одно из достоинств одноранговых сетей — простота обслуживания. Если для обслуживания сети на базе Novell NetWare, как правило, требуется системный администратор, то для поддержания работоспособности одноранговой сети не требуется специально выделенный для этого сотрудник.

Наиболее распространены такие одноранговые сети, как Artisoft LANtastic, LANsmart компании D-Link Systems, Invisible Software NET-30 и Web NOS компании Webcorp. Все эти сетевые средства реализованы как надстройки над OS MS-DOS. На основе ОС Windows 95 и Windows 98 также возможно построение одноранговой сети.

Фирма Novell предложила свое решение для организации работы групп пользователей. Сетевая оболочка Novell NetWare Lite напоминает одноранговые сетевые оболочки тем, что для организации сети не требуются выделенные файл-серверы, облегчено совместное использование дисков и принтеров. Novell NetWare Lite запускается как набор резидентных программ в среде MS-DOS. Однако Novell NetWare Lite не является одноранговой сетью. Скорее, это сеть с централизованным управлением, в которой может быть несколько невыделенных или выделенных серверов.

В целом Novell NetWare Lite представляет достаточно удачное решение для организации небольших сетей. Кроме того, Novell NetWare Lite хорошо уживается с Novell NetWare 3.11, что позволяет комбинировать возможности сетей с централизованным управлением на базе NetWare 3.11 с удобным разделением ресурсов отдельных рабочих станций.

Из всего разнообразия сетевых OS и оболочек самые распространенные изделия — Novell NetWare и Windows NT 4.0 (NT Server и NT Workstation). Сегодня Microsoft продает Windows 2000 Server и запускает Windows.NET Server (пока вышла бета-версия 3).

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

Компоненты сетевой операционной системы на каждой рабочей станции и файловом сервере взаимодействуют друг с другом в рамках соглашений, называемых протоколом. Одним из общих протоколов является протокол фирмы IBM NetBIOS (Network Basic Input Output System —

Сетевая операционная система ввода-вывода). Другим распространенным протоколом является IPX {Internet-work Packet Exchange — Межсетевой обмен пакетами) фирмы Novell.

В таблице приведен список некоторых сетевых операционных систем с указанием их производителей.

Рассмотрим некоторые из этих операционных систем.

Операционная система NetWare

ОС NetWare фирмы Novell. Novell была одной из первых компаний, которые начали создавать ЛВС.

Она производила как аппаратные средства, так и программные, однако в последнее время фирма Novell сконцентрировала усилия на программных средствах ЛВС.

Приведем некоторые характеристики программных продуктов NetWare.

В среде NetWare способно работать большее количество приложений, чем в любой другой ЛВС. ОС NetWare способна поддерживать рабочие станции, управляемые DOS, DOS и Windows, OS/2, UNIX, Windows NT, Mac System 7 и другими ОС. ЛВС NetWare может работать с большим количеством различных типов сетевых адаптеров, чем любая другая операционная система. Для достижения поставленных целей вы можете выбрать аппаратные средства от множества разных поставщиков. С NetWare можно использовать Arcnet, Ethernet, Token Ring или практически любой другой тип сетевого адаптера.

Средства защиты данных, предоставляемые NetWare, более чем достаточны для большинства ЛВС.

NetWare допускает использование более чем 200 типов сетевых адаптеров, более чем 100 типов дисковых подсистем для хранения данных, устройств дублирования данных и файловых серверов.

Фирма Novell имеет контракты о поддержке ОС NetWare с наиболее крупными и мощными из независимых организаций, таких как Bell Atlantic, DEC, Hewlett-Packard, Intel, Prime, Unisys и Xerox.

Операционные системы UNIX и LINUX

Операционные системы UNIX и LINUX имеют большую известность как сете­вые операционные системы, чем Novell NetWare. Они реже используются как ОС локальных сетей. Основное их назначе­ние — обеспечение доступа к глобальным сетям и их сервисам.

Независимо от версии общими для UNIX чертами являются:

• многопользовательский режим со средствами защиты данных от несанкци­онированного доступа;

• реализация мультипрограммной обработки в режиме разделения времени, основанная на использовании алгоритмов вытесняющей многозадачности (preemptive multitasking);

• использование механизмов виртуальной памяти и свопинга для повышения уровня мультипрограммирования;

• унификация операций ввода-вывода на основе расширенного использования понятия «файл»;

• иерархическая файловая система, образующая единое дерево каталогов незави­симо от количества физических устройств, используемых для размещения файлов;

• переносимость системы за счет написания ее основной части на языке Си;

• разнообразные средства взаимодействия процессов, в том числе и через сеть;

• кэширование диска для уменьшения среднего времени доступа к файлам.

Для глобальных сетей UNIX и UNIX-подобные системы (например, LINUX) являются основными. Здесь важно подчеркнуть, что UNIX прозрачным образом поддерживает не только работу с удаленного терминала (даже по телефонной линии), но и электронную почту, и набор протоколов TCP/IP. При этом детали обмена данными между компьютерами от пользователя системы скрыты, и он может, работая за любым компьютером сети или за удаленным терминалом, выполнять разнообразные операции и даже запускать процессы, не зная, где физически находится исполняющий компьютер.

В основе UNIX лежит концепция процесса — единицы управления и единицы потребления ресурсов. Процесс представляет собой программу в состоянии выпол­нения, причем в UNIX в рамках одного процесса не могут выполняться никакие параллельные действия.

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

При управлении процессами операционная система использует два основных типа информационных структур: дескриптор процесса (структура ргос) и контекст процесса (структура user).

В UNIX реализован механизм виртуальной файловой системы VFS (Virtual File System), который позволяет ядру системы одновременно поддерживать несколько различных типов файловых систем. Механизм VFS поддерживает для ядра некото­рое абстрактное представление о файловой системе, скрывая от него конкретные особенности каждой файловой системы.

Рис. 1 Традиционная файловая система s5

Необходимо отметить, что файловая система хорошо известных операционных систем DOS и Windows создавалась на основе идеологии традиционной файловой системы UNIX, поэтому у них можно обнаружить определенное сходство.

По функциональному назначению различают обычные файлы, каталоги и специальные файлы.

В UNIX для файла существуют три типа имени: краткое имя, полное и относительное.

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

ОС UNIX остается сложной в освоении универсальной операционной системой, обладающей избыточными возможностями по отношении к использованию на персональных компьютерах, задачам поддержки локальной сети и обеспечению доступа к глобальным сетям. В связи с этим в появилась система Linux. Linux широко распространена на платформах Intel PC и завоевывает позиции на ряде других платформ (DEC, Apple и др.).

ОС Linux имеет следующие достоинства:

• дает возможность бесплатно и легально иметь современную ОС для использования как на работе, так и дома;

• обладает высоким быстродействием;

• работает надежно, устойчиво, совершенно без зависаний;

• не подвержена вирусам;

• позволяет использовать полностью возможности современных ПК, снимая ограничения, присущие MS Windows по использованию памяти машины и ресурсов процессора(ов);

• эффективно управляет многозадачностью и приоритетами, фоновые задачи (длительный расчет, передача электронной почты по модему, форматирование дискеты и т.д.) не мешают интерактивной работе;

• позволяет легко интегрировать компьютер в локальные и глобальные сети, в том числе в Интернет; работает с сетями на базе Novell и MS Windows;

• позволяет выполнять представленные в формате загрузки прикладные программы других ОС — различных версий UNIX и MS Windows;

• обеспечивает использование огромного числа разнообразных программных пакетов, накопленных в мире UNIX и свободно распространяемых вместе с исходными текстами;

• предоставляет богатый набор инструментальных средств для разработки прикладных программ любой степени сложности, в том числе системы класса клиент—сервер, объектно-ориентированные, с многооконным текстовым и/или графическим интерфейсом, пригодных для работы как в Linux, так и в других ОС;

• дает пользователю и особенно разработчику замечательную учебную базу в виде богатой документации и исходных текстов всех компонент, включая ядро самой ОС;

• дает всем желающим попробовать свои силы в разработке, организовать общение и совместную работу через Интернет с любыми из разработчиков ОС Linux и сделать свой вклад, став соавтором системы.

Операционная система Windows NT

При разработке структуры Windows NT по аналогии с NetWare и UNIX была использована концепция микроядра. В соответствии с этой идеей ОС разделена на несколько подсистем, каждая из которых выполняет отдельный набор сервисных функций, например сервис памяти, сервис по созданию процессов или сервис по планированию процессов. Каждая подсистема выполняется в пользовательском режиме, осуществляя цикл проверки запроса от клиента на одну из его сервисных функций. Клиент, которым может быть либо другая компонента ОС, либо прикладная программа, запрашивает сервис, посылая сообщение на сервер. Ядро ОС (или микроядро), работая в привилегированном режиме, доставляет сообщение нужному серверу, затем сервер выполняет операцию, после этого ядро возвращает результаты клиенту с помощью другого сообщения.

Структурно Windows NT может быть представлена в виде двух частей: часть операционной системы, работающая в режиме пользователя, и часть операционной системы, работающая в режиме ядра (рис. 2).

Рис. 2 Структура Windows NT

Поддержку защищенных подсистем обеспечивает исполнительная часть Windows NT executive, которая работает в пространстве ядра и никогда не сбрасывается на диск. Ее составными частями являются:

• менеджер объектов. Создает, удаляет и управляет объектами NT executive – абстрактными типами данных, используемых для представления ресурсов системы;

• монитор безопасности. Устанавливает правила защиты на локальном компьютере. Охраняет ресурсы операционной системы, выполняет защиту и регистрацию исполняемых объектов;

• менеджер процессов. Создает и завершает, приостанавливает и возобновляет процессы и нити, а также хранит о них информацию;

• менеджер виртуальной памяти;

• подсистема ввода-вывода. Включает в себя следующие компоненты:

1) менеджер ввода-вывода, предоставляющий средства ввода-вывода, независимые от устройств;

2) файловые системы — NT-драйверы, выполняющие файл-ориентированные запросы на ввод-вывод и транслирующие их в вызовы обычных устройств;

3) сетевой редиректор и сетевой сервер — драйверы файловых систем, передающие удаленные запросы на ввод-вывод на машины сети и получающие запросы от них;

4) драйверы устройств NT executive — низкоуровневые драйверы, которые непосредственно управляют устройством;

5) менеджер кэша, реализующий кэширование диска.

Исполнительная часть, в свою очередь, основывается на службах нижнего уровня, предоставляемых ядром (его можно назвать и микроядром) NT. В функции ядра входит:

• планирование процессов;

• обработка прерываний и исключительных ситуаций;

• синхронизация процессоров для многопроцессорных систем;

• восстановление системы после сбоев.

Windows NT использует защищенные подсистемы в следующих целях:

• обеспечение нескольких программных интерфейсов (API), по возможности не усложняя при этом базовый программный код (NT executive);

• изоляция базовой ОС от изменений или расширений в поддерживаемых API;

• объединение части глобальных данных, требующихся всем API, и в то же время отделение данных, использующихся каждым отдельным API от данных, использующихся другими API;

• защита окружения каждого API от приложений, а также от окружений других API, и защита базовой ОС от различных окружений;

• расширение ОС в будущем благодаря новым API.

Микроядро NT служит, главным образом, средством поддержки для переносимой основной части ОС — набора пользовательских сред. Концентрация машинно-зависимых программ внутри микроядра делает перенос NT на разнообразные процессоры относительно легким.

В Windows NT реализована вытесняющая многозадачность, при которой операционная система не ждет, когда нить сама захочет освободить процессор, а принудительно снимает ее с выполнения — после того как та израсходовала отведенное ей время (квант) или если в очереди готовых появилась нить с более высоким приоритетом. При такой организации разделения процессора ни одна нить не займет процессор на очень долгое время.

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

Чтобы помочь производителям избежать этого, Windows NT обеспечивает интерфейс и программную среду, называемые «спецификация интерфейса сетевого драйвера» (NDIS), которые экранируют сетевые драйверы от деталей различных транспортных протоколов. Самый верхний уровень драйвера сетевого адаптера должен быть написан в соответствии с рекомендациями NDIS. В этом случае пользователь может работать с сетью TCP/IP и сетью NetBEUI (или DECnet, NetWare, VINES и т.п.), используя один сетевой адаптер и один сетевой драйвер.

Операционная система Windows 2000

Windows 2000, является потомком NT, обладает всеми ее достоинствами, а многие из ее ограничений при этом снимает. Windows 2000 — один из крупнейших программных продуктов, его код содержит около 30 млн. строк. В Windows 2000 появилась поддержка шины USB, РС-карт, шины AGP и DVD-устройств, а также технологии Plug and Play , которой славится Windows 98, — автоматического распознавания и установки устройств.

Для инсталляции Windows 2000 Professional нужно не менее 650 Мбайт свободного дискового пространства, но на некоторых машинах может потребоваться до 1 Гбайт. В установленном виде система занимает около 500 Мбайт — примерно вдвое больше, чем Windows 98.

Заметно расширены в Windows 2000 возможности работы с файловыми системами. Помимо используемых в Windows 9x файловых систем FAT16 и FAT32 (незащищенных), эта ОС работает с NTFS5 (NT File System 5), специально разработанной для Windows 2000 усовершенствованной версией файловых систем с добавлением шифрования и других новых возможностей. Она обеспечивает более эффективное использование дискового пространства и лучшую защиту информации.

Важным шагом вперед в защиту данных в Windows 2000 явилась технология Kerberos. Kerberos — это протокол аутентификации, обеспечивающий передачу данных по незащищенным сетям. Именно он наряду со службой каталогов Active Directory (AD) составляет важнейшую особенность Windows 2000, отличающую эту систему от Windows NT 4.0. Kerberos обеспечивает создание транзитивных доверительных отношений, тогда как NT 4.0 позволяет формировать лишь нетранзитивные. Эту идею можно пояснить на простом примере: если Х доверяет некоторому человеку У, а он, в свою очередь, доверяет Z, то, в соответствии с логикой формирования транзитивных отношений, этого уже достаточно, чтобы Х доверял Z. Эта особенность протокола Kerberos как раз и позволяет системе Windows 2000 формировать деревья и леса доменов. Другая сильная сторона протокола — функция взаимной аутентификации, т. е. возможность любого члена каждой пары «клиент-сервер» проверять полномочия своего партнера. Эта функция снимает такую характерную для Windows NT Workstation 4.0 проблему, как уязвимость для атак со стороны систем, выдающих себя за серверы.

ОС Windows 2000 оснащается средствами защиты информации на базе инфраструктуры открытых ключей (Public Key Infrastructure — PKI). Эта инфраструктура представляет собой систему цифровых сертификатов и организаций, удостоверяющих сертификаты (Certificate Authorities — CAs). Также, как и протокол Kerberos, она дает возможность обоим участникам транзакции проверять, действительно ли партнер является тем, за кого себя выдает, а также шифровать транзакции. Система защиты данных на базе PKI лучше всего подходит для использования в сети Интернет и потому представляет собой полезное средство для организации электронной коммерции между предприятиями.

В состав системы входит вполне добротный маршрутизатор с интерфейсом подключения по запросу (Demand-Dial Interface – DDI), так что при появлении на интерфейсе модема трафика автоматически устанавливается соединение с Интернетом. С помощью таких средств, как реализованные в Windows 2000 Server и в Windows 2000 Professional модуль Internet Connection Sharing, доступ к предоставляемому системой выходу в Интернет получают сразу несколько пользователей сети. Этот модуль реализует технологию трансляции сетевых адресов (Network Address Translation — NAT): маршрутизатор (т.е. сервер) транслирует трафик «локальная сеть — Интернет» в трафик между множеством локальных узлов и одним сетевым IP-адресом.

Службой Terminal Services сервера Windows 2000 Server можно пользоваться без какой-либо предварительной настройки. Эта функция обеспечивает доступ к удаленным серверам, причем пользователь получает такую же степень свободы, как если бы он зарегистрировался с консоли системы.

Windows 2000 оснащена усовершенствованными средствами симметричной многопроцессорной обработки, обеспечивающими более «гладкую», чем Windows NT 4.0, настройку операционной системы для работы с числом процессоров свыше четырех. Кроме того, надо иметь в виду, что сервер Windows 2000 Datacenter Server (Datacenter) выступает в качестве конкурента серверов UNIX с числом процессоров до 32 и оснащенных физической памятью емкостью 64 Гбайт.

Windows 2000 и ее предшественница Windows NT 4.0 не могли соперничать с мощными версиями UNIX. С появлением Datacenter Microsoft надеется выровнять положение, задействовав Windows на более крупных и мощных машинах, чем когда-либо до этого. Благодаря дополнительным возможностям повышается уровень масштабируемости, готовности и управляемости Windows 2000. Специальные требования к сертификации и техническому обслуживанию еще более выделяют эту операционную систему среди остальных серверов семейства Windows 2000. В таблице 1 приведены сравнительные характеристики Windows 2000 Server, Windows 2000 Advanced Server (AS) и Datacenter.

Таблица 1 Сравнительные характеристики Windows 2000 Server

28 ПО общего назначения

«ПК Входящая-исходящая документация» (“InOutD”)  1. Назначение и условия функционирования

1.1 Назначение Программное средство “ InOutD ” предназначено для автоматизации ведения журналов входящей и исходящей корреспонденции в учреждениях, в структуре которых  обязательно наличие отделов. Предоставляется возможность регистрации документов, их распределение для исполнения по отделам и контроль своевременного исполнения.  Осуществляется быстрый поиск нужных документов и возможность просмотра их электронных копий.

1.2 Функции  Программное средство “InOutD” обеспечивает реализацию следующих функций:

•     регистрация входящих документов секретарем учреждения, внесение резолюции руководителя и распределение документов по начальникам отделов;

•     постановка документов на контроль и их снятие с контроля;

•     наблюдение за своевременным исполнением документов и их распределением по отделам;

•     создание ссылки на электронную копию документа для возможности его просмотра;

•     печать журналов регистрации входящих и исходящих документов;

•     поиск зарегистрированных документов по различным признакам;

•     внесение резолюции начальником отдела;

•     распределение документов среди сотрудников отдела и анализ их распределения  среди сотрудников;

•     регистрация исходящих документов;

•     регистрация приказов.

1.3 Условия функционирования Программное средство “InOutD”, далее просто ПС, функционирует под управлением СУБД VISUAL FOXPRO V 6.0 на ПК стандартной конфигурации с расширенной памятью в среде WINDOWS 98, 2000, XP в локальном или сетевом варианте. Разрешение рабочей области экрана монитора должно быть не менее 800х600 точек. В случае работы в сети необходимо программу и базу данных (БД) располагать на сервере и администратору сети обеспечить доступ пользователей к соответствующим каталогам.

29 ПО поиска неисправности в сети

Поиск неисправностей в сети.  Поиск неисправностей в сети - это сочетание анализа (измерения, диагностика и локализация ошибок) и синтеза (принятие решения о том, какие изменения надо внести в работу сети, чтобы исправить ее работу).  Анализ - определение значения критерия эффективности (или, что одно и то же, критерия оптимизации) системы для данного сочетания параметров сети.  Из этого этапа выделяется подэтап мониторинга, на котором выполняется более простая процедура - процедура сбора первичных данных о работе сети: статистики о количестве циркулирующих в сети кадров и пакетов различных протоколов, состоянии портов концентраторов, коммутаторов и маршрутизаторов и т.п. Далее выполняется этап собственно анализа, под которым в этом случае понимается более сложный и интеллектуальный процесс осмысления собранной на этапе мониторинга информации, сопоставления ее с данными, полученными ранее, и выработки предположений о возможных причинах замедленной или ненадежной работы сети.  Задача мониторинга решается программными и аппаратными измерителями, тестерами, сетевыми анализаторами и встроенными средствами мониторинга систем управления сетями и системами.  Задача анализа требует более активного участия человека, а также использования таких сложных средств как экспертные системы, аккумулирующие практический опыт многих сетевых специалистов.  Синтез - выбор значений варьируемых параметров, при которых показатель эффективности имеет наилучшее значение. Если задано пороговое значение показателя эффективности, то результатом синтеза должен быть один из вариантов сети, превосходящий заданный порог.  Приведение сети в работоспособное состояние - это также синтез, при котором находится любой вариант сети, для которого значение показателя эффективности отличается от состояния "не работает". Синтез рационального варианта сети - процедура чаще всего неформальная, так как она связана с выбором слишком большого и очень разнородного множества параметров сети - типов применяемого коммуникационного оборудования, моделей этого оборудования, числа серверов, типов компьютеров, используемых в качестве серверов, типов операционных систем, параметров этих операционных систем, стеков коммуникационных протоколов, их параметров и т.д. и т.п. Очень часто мотивы, влияющие на выбор "в целом", то есть выбор типа или модели оборудования, стека протоколов или операционной системы, не носят технического характера, а принимаются из других соображений - коммерческих, "политических" и т.п. Поэтому формализовать постановку задачи оптимизации в таких случаях просто невозможно. В данной книге основное внимание уделяется этапам мониторинга и анализа сети, как более формальным и автоматизируемым процедурам. В тех случаях, когда это возможно, в книге даются рекомендации по выполнению некоторых последовательностей действий по нахождению рационального варианта сети или приводятся соображения, облегчающие его поиск. Обнаружение проблем в сетевом окружении.  Основные проблемы, которые могут возникать в сетевом окружении: 

• потеря или невозможность соединения компьютеров в подсети и/или в домене, 

• уменьшение скорости обмена данными, 

• невозможность получить доступ к общим ресурсам сети - папкам, каталогам, принтерам и т.д, 

• невозможность получения IP-адреса от сервиса DHCP, 

• невозможность установления связи с компьютерами других доменов, 

• нарушение функционирования сетевого взаимодействия с использованием безопасности IP, 

• недоступность со стороны компьютера-клиента серверных компонентов.

Проверить наличие или отсутствие соединений с другими компьютерами в сети можно в папке Cетевое окружение, открыв папку Вся сеть (дважды щелкнув соответствующий значок). В папке Вся сетьдоступна сеть Microsoft Windows Network. Открыв ее, можно увидеть значки с именами доступных доменов подсетей, и далее, значки компьютеров входящих в эти подсети. Отсутствие значков уже говорит об отсутствии соединений. Но если соединение с каким-либо компьютером внезапно пропадет, то попытка открыть этот компьютер вызовет задержку в работе проводника на период срабатывания тайм-аута и система выведет сообщение об отсутствии в сети ресурса. Аналогично обстоит дело с доступом к каталогу Active Directory, значок которого Каталог находится там же, в папке Вся сеть. Поиск неисправностей в сети. Утилиты TCP/IP.  Windows XP предоставляет в ваше распоряжение широкий набор утилит для управления, конфигурирования и выявления неисправностей среды TCP/IP. Ping - диагностическая утилита, которая проверяет возможность соединения с удаленным компьютером.  Pathping - усовершенствованная утилита ping, которая также отражает маршрут прохождения и предоставляет статистику потери пакетов на промежуточных маршрутизаторах.  Route - показывает и позволяет изменять конфигурацию локальной таблицу маршрутизации.  Tracert - отслеживает маршрут, по которому пакеты перемещаются на пути к пункту назначения.  Netstat - показывает текущую информацию сетевого соединения TCP/IP. Например, информацию о подключенном хосте и номера используемых портов.  Ipconfig - показывает текущую конфигурацию TCP/IP на локальном компьютере.  Hostname - показывает локально настроенное имя узла TCP/IP ..  Arp - показывает и позволяет изменять кэш протокола ARP (Address Resolution Protocol), где хранится информация о соответствии IP - адресов - MAC - адресам локальных узлов.  Nslookup - утилита командной строки - распознаватель для запросов DNS сервера.  Утилиты выполняются из командной строки.  Чтобы открыть окно командной строки нажмите кнопку Пуск и выберите последовательно команды Все программы -> Стандартные -> Командная строка. Если не удается подключиться к другому компьютеру, могут иметь место неполадки с подключением или неполадки с именами. Применение утилит ping и ipconfig.  Чтобы определить причину неполадок, попытайтесь выполнить обмен пакетами (утилита ping) с IP-адресом другого компьютера. Таким компьютером может быть компьютер, с которым вы пытаетесь соединиться, или основной шлюз.  Чтобы определить IP-адрес основного шлюза: наберите в командной строке ipconfig и нажмите клавишу ENTER. Если требуемая информация уходит с экрана, то для просмотра экранов по очереди введите ipconfig | more и нажмите клавишу ENTER. В отображаемых результатах найдите строку Основной шлюз и запишите соответствующий IP-адрес.  Чтобы выполнить обмен пакетами (ping) с другим компьютером: наберите в командной строке: ping адрес, где адрес представляет IP-адрес другого компьютера, и нажмите клавишу ENTER.  Если обмен пакетами выполнен успешно, появляется отклик, аналогичный следующему: Ответ от <адрес> число байт=32: Ответ от <адрес>: число байт=32 время=75мс TTL=28 Ответ от <адрес>: число байт=32 время=87мс TTL=28 Если обмен пакетами выполнить не удается, появляется отклик, аналогичный следующему:  Ответ от <адрес> число байт=32: Превышен интервал ожидания. Превышен интервал ожидания. Утилита Ipconfig показывает текущую конфигурацию TCP/IP на локальном компьютере. Ключи утилиты:  /release - освобождает полученный от DHCP IP - адрес. /renew - получает от DHCP новый IP - адрес. /all - показывает всю информацию о TCP/IP конфигурации. /flushdns - очищает кэш локального распознавателя DNS. /regsiterdns - обновляет адрес в DHCP и перерегистрирует его в DNS. /displaydns - показывает содержание кэша распознавателя DNS.

30 ПО поиска неисправности в сети

В данном руководстве содержатся советы по поиску и устранению сетевых проблем (локальная сеть), характерных для встроенных решений локальных сетей (LAN) на системных платах Intel® для настольных ПК.

Общая информация

• Как определить версию сетевого драйвера

• Где найти последние версии сетевых драйверов

• Как обновить сетевые драйверы

• Установка дополнительных сетевых плат

• Включение среды сетевой загрузки PXE

• Конфигурирование Wake-on-LAN

• Использование технологии Intel® Active Management

• Большие кадры

Поиск и устранение неисправностей

• После обновления драйвера сетевого адаптера возникает сетевая ошибка

• Ошибка: “This connection has limited or no connectivity” (Соединение ограничено или отсутствует).

• Периодические ошибки сетевой подсистемы на системной плате Intel® DG31PR для настольных ПК

• Проблемы сетевого подключения

Общая информация Как определить версию сетевого драйвера

Для Windows 7*:

1. Нажмите Пуск > правой кнопкой мыши нажмите Компьютер >Управление.

2. Выберите Диспетчер устройств.

3. Откройте раздел Сетевые адаптеры.

4. Нажмите правой кнопкой мыши на адаптер и выберите вкладкуСвойства.

5. Перейдите на вкладку Драйвер (Driver), чтобы увидеть текущую версию драйвера.

Для Windows Vista:

1. Нажмите Пуск > Настройки > Панель управления > Система >Диспетчер устройств.

2. Откройте раздел Сетевые адаптеры.

3. Нажмите правой кнопкой мыши на адаптер и выберите вкладкуСвойства.

4. Перейдите на вкладку Драйвер (Driver), чтобы увидеть текущую версию драйвера.

В Microsoft Windows XP*:

1. Нажмите Пуск (Start) > Панель управления (Control Panel) > Система и ее обслуживание (Performance and Maintenance) > Система(System).

2. Перейдите на вкладку Аппаратные средства и выберите Менеджер устройств.

3. Откройте раздел Сетевые адаптеры.

4. Нажмите правой кнопкой мыши на адаптер и выберите вкладкуСвойства.

5. Перейдите на вкладку Драйвер (Driver), чтобы увидеть текущую версию драйвера.

Для Microsoft Windows 98SE, ME или 2000*:

1. Нажмите Пуск (Start) > Настройки (Settings) > Панель управления(Control Panel).

2. Два раза нажмите Система (System).

3. Перейдите на вкладку Аппаратные средства и выберите Менеджер устройств.

4. Откройте раздел Сетевые адаптеры.

5. Нажмите правой кнопкой мыши на адаптер и выберите вкладкуСвойства.

6. Перейдите на вкладку Драйвер (Driver), чтобы увидеть текущую версию драйвера.

Где найти последние версии сетевых драйверов Вы можете скачать последние версии сетевых драйверов для Вашей системной платы Intel® в центре загрузки Intel.

Как обновить сетевые драйверы

1. Загрузите версию сетевого драйвера в центре загрузки Intel.

2. Дважды нажмите на загруженный файл, чтобы извлечь и установить обновленные драйверы.

Установка дополнительных сетевых плат Если Вы хотите установить сетевую плату стороннего производителя вместо интегрированного сетевого решения, выполните следующие действия.

Отключение интегрированной сетевой платы:

1. Во время начальной загрузки нажмите F2, чтобы войти в режим конфигурирования BIOS.

2. Перейдите в меню Advanced (Дополнительно) > Peripherals Configuration (конфигурация периферийных устройств).

3. Отключение интегрированного сетевого решения.

4. Сохраните изменения, нажав F10, и выйдите из режима конфигурирования BIOS.

Установите карту дополнительную сетевую плату стороннего производителя в соответствии с инструкциями.

Включение среды сетевой загрузки PXE В системных платах Intel® для настольных ПК с поддержкой предзагрузочной среды (PXE) можно выбрать сетевое устройство в качестве загрузочного. Это позволяет произвести загрузку с интегрированного сетевого решения.

Чтобы использовать сетевое устройство в качестве загрузочного, выполните следующее:

1. Во время начальной загрузки нажмите F2, чтобы войти в режим конфигурирования BIOS.

2. Перейдите в меню Boot.

3. Включите функцию Boot to Network.

4. Сохраните изменения, нажав F10, и выйдите из режима конфигурирования BIOS.

При нажатии клавиши <F12> во время процедуры POST форсируется загрузка с сетевого диска. Для использования этой клавиши во время процедуры POST, параметру User Access Level в программе настройки BIOS должно быть присвоено значение Full.

Конфигурирование Wake-on-LAN Wake-on-LAN - это аппаратно-программное решение, позволяющее удаленно пробудить компьютер. Компьютер, совместимый с интерфейсом управления конфигурацией и питанием (ACPI), можно включить удаленно из любой точки мира при условии, что он подключен к Интернету.

Вначале функция Wake-on-LAN должна быть включена в BIOS системной платы для настольных ПК, а затем настроена в операционной системе.

Чтобы включить функцию Wake-on-LAN, выполните следующие действия:

1. Во время начальной загрузки нажмите F2, чтобы войти в режим конфигурирования BIOS.

2. Перейдите к меню Power.

3. Установите параметр Wake-on-LAN в положение Power On (Включено).

4. Сохраните изменения, нажав F10, и выйдите из режима конфигурирования BIOS.

Чтобы настроить функцию Wake-on-LAN в операционной системе, выполните следующие действия:

1. Нажмите Пуск (Start) > Настройки (Settings) > Панель управления(Control Panel).

2. Два раза нажмите Система (System).

3. Перейдите на вкладку Аппаратные средства и выберите Менеджер устройств.

4. Откройте раздел Сетевые адаптеры.

5. Нажмите правой кнопкой мыши на адаптер и выберите вкладкуСвойства.

6. Откройте закладку Дополнительно.

7. Выберите Wake-on-LAN Options (Параметры Wake-on-LAN) и выберите вкладку Properties (Свойства). Установите следующее:

• Включение PME: Установите Enabled

• Настройки функции Wake on: выберите Wake on Magic Packet

Использование технологии Intel® Active Management Технология Intel® Active Management (Intel® AMT) – это аппаратное решение, использующее коммуникации по внештатному каналу для управления клиентскими системами независимо от их состояния. Даже при отказе жесткого диска и заблокированной операционной системе Вы сможете получить доступ к клиентскому компьютеру для выполнения базовых управленческих задач.

Инструкции по базовой настройке системы и информация об использовании Web-браузера для доступа к клиентской системе посредством AMT доступны в Руководстве по быстрому запуску.

Дополнительные функции Intel® AMT реализованы разработчиками в виде программного обеспечения, поддерживающего эту новую технологию управления.

Большие кадры В некоторых гигабитных сетевых адаптерах Intel®, поддерживающих большие кадры, установлено ограничение на размер кадров до 9328 байт и соответствующее ограничение на максимальный размер пакета (MTU) до 9216 байт. Это ограничение оказывает влияние на следующие компоненты сетевого решения системных плат Intel® для настольных ПК:

• Гигабитный сетевой контроллер Intel® 82547EI

Следующие гигабитные сетевые адаптеры, входящие в комплектацию системных плат Intel® для настольных ПК, не поддерживают большие кадры:

• Гигабитный сетевой контроллер Intel® 82566DM

• Гигабитный сетевой контроллер Intel® 82566DC

• Гигабитный сетевой контроллер Intel® 82573E

• Гигабитный сетевой контроллер Intel® 82573V

• Гигабитный сетевой контроллер Intel® 82573L

Поиск и устранение неисправностей

Поиск и устранение неисправностей В некоторых случаях, при использовании сетевого драйвера версии 14.7, 14.8 или 15.1 MAC-адрес системы меняется на 00.00.00.00.00.00, в результате чего происходит сбой сетевого соединения. Для решения данной проблемы обновите версию сетевого драйвера до версии 15.3 или выше.

Ошибка: “This connection has limited or no connectivity.” (Соединение ограничено или отсутствует). При использовании Microsoft Windows* XP Service Pack 2 возможно возникновение следующих проблем:

• На панели задач возникает следующее сообщение: “This connection has limited or no connectivity (Соединение ограничено или отсутствует). You might not be able to access the Internet or some network resources” (Возможно, Вы не сможете получить доступ к Интернету или другим сетевым ресурсам).

• Возникли проблемы при подключении к Интернету или локальной сети.

• При попытке подключения система зависает на этапе «Acquiring IP Address» (Определение IP-адреса).

Загрузите и установите обновление для Windows XP* Service Pack 2 (KB884020)

Периодические ошибки сетевой подсистемы на системной плате Intel® DG31PR для настольных ПК Если у вас возникают ошибки сетевого подключения на системной плате Intel® DG31PR для настольных ПК, попробуйте обновить драйвер сетевой платы до последней версии. Новейшую версию драйвера можно загрузить вцентре загрузки Intel.

Проблемы сетевого подключения Проблемы сетевого подключения быть вызваны различными причинами. Информация по устранению возникших проблем с сетевым подключением содержится в следующих статьях:

Как выявить и устранить основные проблемы, связанные с Internet Explorer* Как выявить и устранить основные проблемы, связанные с TCP/IP Как выявить и устранить проблемы подключения TCP/IP к ОС Microsoft Windows XP* Как выявить и устранить проблемы в домашней сети на базе ОС Microsoft Windows XP Как выявить и устранить проблемы с сетевым подключением

31 ПО анализа и оптимизации сети

Оптимизация сетей позволяет операторам сотовой связи решать такие актуальные на сегодняшний момент задачи, напрямую влияющие на доход оператора:

1. Максимально эффективно использовать существующие ресурсы сети, что позволяет экономить на необязательном расширении различных элементов сети.

2. Уменьшать потери трафика в сети: любой неуспешный звонок абонента (оборванные не по инициативе абонента или несостоявшийся вызов) уменьшает доход оператора.

3. Повышать лояльность абонентов за счет улучшения качества предоставления услуг. Затраты на привлечение нового абонента значительно превышают затраты на повышение лояльности. Более того, чем выше качества предоставляемых услуг, тем большее количество дополнительных услуг будет пользоваться среди абонентов спросом.

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

С точки зрения предоставления услуги по оптимизации можно выделить 2 основных блока, каждый из которых состоит из нескольких модулей:

1. Первоначальная оценка текущего состояния сети (своего рода аудит сети) состоит из двух модулей: 

Оценка качества сети:

• Анализ статистики BSS

• Анализ статистики GPRS

• Анализ статистики SSS

• Анализ трассировок А-интерфейса

• Анализ трассировок Gb-интерфейса

Оценка качества сети E2E тестами:

• Проведение драйв-тестов

• Анализ качества передачи речи

• Анализ качества передачи данных

• Проведение benchmark драйв-тестов (сравнение с сетями конкурентов)

2. Оптимизация сети включает в себя следующие модули:

Оптимизация подсистемы базовых станций (как для голосовой услуги, так и для пакетной передачи трафика):

• Анализ основных показателей качества

• Оптимизация соотношений «по соседям»

• Анализ параметров баз данных BSC и их корректировка

• Предложения по активации новых опций

• Выборочная проверка наиболее проблемных сайтов

Оптимизация подсистемы коммутации (как для голосовой услуги, так и для пакетной передачи трафика)

• Анализ основных показателей качества

• Определение трафик-модели

• Анализ трассировок различных интерфейсов

• Оптимизация баз данных MSC, SGSN

• Выявление перегруженных направлений

2G/3G оптимизация:

• Распределение трафика между 2G/3G иерархическими уровнями сети

• Обеспечение эффективной работы между слоями 2G/3G

Ниже приводятся основные задачи, решаемые в процессе оптимизации подсистемы базовых станций:

Определение основных показателей качества (KPI):

• Проводится согласование списка показателей качества, по которым проводится оценка сети, а также формул для вычисления KPI.

• Оговариваются значения, которые предполагается достичь в результате оптимизации.

Мониторинг и анализ качества работы сети радиодоступа подсистемы BSS:

• Мониторинг качества работы подсистемы BSS

• Наблюдение за изменениями конфигурации при помощи специальных программных средств для анализа сети радиодоступа

• Определение основных проблемных зон, разработка рекомендаций по улучшению качества работы сети

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

Мониторинг и оптимизация соотношений «по соседям»

Проводится анализ имеющихся соотношений «по соседям»:

• при помощи специального программного обеспечения

• на основе статистических данных

• на основе результатов драйв-тестов

Предоставляются таблицы, в которых для сот будут определены необходимые «соседи».

Анализ параметров базы данных контроллеров и их корректировка Проверка измененных параметров баз данных контроллеров и их уточнение

• Разработка значений логических параметров БС и их последующая настройка

• Анализ взаимосвязанных логических параметров (особенно соотношения таймеров)

• Создание необходимых RC-скриптов для реализации предложенных значений логических параметров.

Предложения по внедрению новых опций

Разработка значений логических параметров для эффективной работы опций

• Предложения по установке логических параметров в случае активации новых опций

• Создание необходимых RC-скриптов для реализации предложенных значений логических параметров.

Поддержка 1-го уровня с выездом на сайты

• Поддержка с выездом на сайт при проведении инспекции установленного оборудования, согласно техническим предписаниям и нормам по монтажу и эксплуатации оборудования.

При оптимизации подсистемы коммутации решаются следующие задачи:

Определение основных показателей качества (KPI)

• Проводится согласование списка показателей качества, по которым проводится оценка сети, а также формул для вычисления KPI. 

• Оговариваются значения, которые предполагается достичь в результате оптимизации.

Анализ качества работы подсистемы SSS на основе KPI Анализ емкости подсистемы SSS

Транкгруппы. Анализ позволяет получить представление о:

• состоянии

• количестве

• степени загруженности (utilisation rate, mErl)

• ошибках

для каждой из транкгрупп в ЧНН.

Нагрузка на LTG. Анализ позволяет получить представление о

• статической нагрузке (мЕрл)

• динамической нагрузке (попытки вызовов)

для каждой из LTG

Сигнальная сеть SSNC. Анализ MP и C7 линков позволяет получить представление о

• нагрузке на линксет и каждый линк в частности (мЕрл)

• рапределении нагрузки в пределах линксета

• наличии ретранслированных октетов

• динамической нагрузке МР

Анализ и корректировка баз данных коммутаторов

• Соединения, маршрутизация и SDDPFC

• Нумерация

• Обработка глобальных заголовков (GTT)

• Зависимые друг от друга команды

• ODAGEN

• Сравнение частей баз данных на разных сетевых элементах

• Создание корректирующих баз данных

• Установка корректирующих баз данных

31 краткое описание команд распространенных протоколов

Соединиться по какому-либо протоколу" - слышали такие слова? Кто они, вообще, эти протоколы передачи данных? Этой теме и посвящена данная статья (эта статья несколько сложней для восприятия, чем большинство статей на этом сайте).

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

Про протоколы также обычно говорят, что имеются уровни вложенности сетевых протоколов. Что это означает? Во-первых, есть так называемый физический уровень. Это - просто список определений, каким должен быть сетевой кабель, толщину жил и так далее. Допустим, теперь, кабель исправен. Тогда по нему могут отправляться пакеты с данными. Но какой компьютер примет пакет? Здесь задействуется так называемый канальный уровень - в заголовке пакета указывается физический адрес компьютера - некоторое число, зашитое в сетевой карте (не IP-адрес, а MAC-адрес).

Канальный уровень = уровень Ethernet. Как вы видите (картинку я взял с википедии), пакет содержит некоторый параметр Ethertype, задающий тип пакета. Сами данные зависят от этого типа, и их содержание уже находится на сетевом уровне. Наиболее распространены два протокола: ARP, отвечающий за преобразование IP-адресов в MAC-адреса; и самый существенный протокол - IP. Приведем структуру пакета IP (детализация поля "Data" предудущего рисунка)

Все данные, переносимые по IP уже пересылаются на конкретный IP-адрес (это не мешает посылать широковещательных запросы всем компьютерам локальной сети - просто указывается специальный IP-адрес, например, 192.168.255.255). У протокола IP тоже есть разновидности - в пакете в установленном формате передается число, обозначающее тип протокола. Например, одним из типов протоколов, подчиненных IP, является ICMP, используемый командой ping для проверки, откликается ли компьютер.

Но наиболее распространены два следующих типа: TCP - Transmission Control Protocol и UDP - universal datagram protocol (кстати, мы уже поднялись на транспортный уровень). Отличие же между этими протоколами таково: про протокол TCP говорят, что он "надежный", то есть в процессе обмена данными производится постоянная проверка: а дошел ли пакет до цели? А протокол UDP не предусматривает никакого контроля - отправили дейтаграмму и забыли. Когда такое нужно? Очень просто, например, при прослушивании интернет-радио. Если был сбой и пакет до вас вовремя не дошел, он уже не нужен - просто проскользнули помехи - и вы слушаете дальше. Приведем структуру TCP-пакета (детализация поля "данные" с предудущего рисунка).

Как мы видим, в пакете указывается номер порта, на который отправлен пакет. Обычно номер порта определяет тип протокола на прикладном уровене - какому именно приложению отправлены эти данные. Однако ничего не запрещает использовать нестандартные порты для своих сервисов - просто менее удобно будет пользователям. Наиболее известные протоколы - http (просмотр страниц в интернете), pop3 (получение почты). Чтобы не повторяться, отошлю к списку стандартных портов. Сами данные, получаемые приложением вкладываются в TCP-пакет (поле "данные").

Таким образом, мы получили своеобразную иерархию вложенности пакетов. В Ethernet-пакет вложен IP-пакет, в него TPC или UDP-пакет, а в него - данные, предназначенные конкретному приложению. Просто смерть кащея какая-то.

Что еще интересно, протокол DHCP, отвечающий за получение IP-адреса по MAC-адресу, также находится на прикладном уровне (по умолчанию использует UDP порты 67 и 68) - хоть у компьютера еще нет IP-адреса, он может отсылать широковещательные запросы согласно сетевым настройкам. То же самое можно сказать про протокол DNS, выясняющий IP-адрес по доменному имени.

32 формальные методы описание протоколов

Число эксплуатируемых в настоящее время протоколов обмена данными велико; при этом разрабатываются все новые протоколы, обеспечивающие лавинное развитие сетевых технологий (появилась новая область вычислительной техники, называемая ‘протокольной технологией’).

Классическое (неформально-словесное, например, ранее упомянутые

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

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

Формальные методы описания протоколов могут быть разбиты на две группы - методы первой группы рассматривают объект как автомат (т.н. ‘автоматные методы’), методы второй группы - как ‘черный ящик’, характеризующийся только внешним поведением (т.н. ‘методы последовательностей’).

В качестве представителя первой группы может быть приведен язык ESTELLE (Extended State Transition Language), второй - язык LOTOS

(Language of Temporal Ordering Specification); оба языка разработаны Международной организацией стандартов (ISO) и служат базовыми средствами для описания разрабатывающих международных стандартов [8].

Язык ESTELLE (1983 г.) основан на объединении логики конечного ав-

томата (при добавлении элементов описания архитектурных особенностей

протокольных систем) и языка программирования Pascal; применяемые в

языке LOTOS (1984 г.) методы основаны на концепции временного упорядо-

чения примитивов взаимодействия.

В СССР для конкретного программно-аппаратного окружения был раз-

работан (в рамках инструментального комплекса ‘Архитектор’) реализую-

щий ‘автоматный метод’ язык ОСА (Описание Сетевых Архитектур, основы

и принципы языка впервые опубликованы в 1983 г.), предназначенный для реализации протокольных архитектур на вычислительных комплексах ‘Эльбрус’. В комплект системы входят развитые средства анализа описаний на языке ОСА и средства тестирования и отладки (под конкретную аппаратную часть). С помощью языка OCA были разработаны специализированные протоколы канального и сетевого уровней, транспортный и сеансовый протокол, протоколы для передачи информации и файлов, удаленного диалога и протокол удаленного запуска заданий (некоторый функциональный аналог RPC в Windows’NT).

Кроме вышеприведенных, известны системы проектирования и описания протоколов FAPL (Format and Access Protocol Language, 1978), PANDORA (Protocol Analysis, Design and OpeRation Assesment, 1982), PDIL (Protocol Description and Implementation Language, 1982), ПРАНАС (Каунас-

ский политехнический институт, 1985) и др.

Как и в случае традиционных языков программирования, исходный

текст на языке формального описания протоколов транслируется (после этапа отладки) в машинный код, исполняемый часто (специализированными) процессорами передачи сообщений (IMP - Interface Message Processor).

1. Введение в стандарты сетевых протоколов

Сетевой протокол – это стандарт, написанный на бумаге (или, более точно, в текстовом редакторе на компьютере). Стандарты, использующиеся в Интернете, называются Requests For Comment (RFC) – Запросы на комментарий. Стандарты RFC пронумерованы от 1 и далее. Сегодня существует более 4500 RFC. Большинство из них вышли из употребления, так что до сих пор используются лишь некоторые из первой тысячи.

Международная организация по стандартизации (International Standardization Office – ISO) разработала стандарты системы сетевых протоколов, называемой ISO OSI. Другой организацией, разрабатывающей стандарты коммуникаций, является Международный союз телекоммуникаций (International Telecommunication Union – ITU), который находится в Женеве. Раньше ITU назывался CCITT. Союз основан в 1865 году и является одной из самых старых всемирных организаций (для сравнения, Красный Крест был образован в 1863 году).

Некоторые стандарты разрабатываются Институтом инженеров по электротехнике и электронике (Institute of Electrical and Electronics Engineers – IEEE). RFC, стандарты выпускаемые RIPE (Réseaux IP Européens – Европейская континентальная сеть TCP/IP), и PKCS (Public Key Cryptography Standard – Криптографический стандарт открытого ключа) свободно доступны в Интернете, их очень легко найти. Другие организации (ISO, ITU и т.д.) не дают стандарты бесплатно – за них нужно платить. Если это для вас проблема, вам придется потратить время на поиски в библиотеке.

В начале давайте посмотрим, почему сетевые связи разделены на несколько протоколов. Ответ прост, хотя он и рождает сложные проблемы в различных сферах деятельности. Большинство книг о сетевых протоколах объясняют проблему с помощью метафоры: два иностранца (философа, доктора и т.п.) пытаются общаться друг с другом. Каждый из них владеет только своим родным языком. Для того, чтобы они могли общаться, им нужен переводчик (Рисунок 2.1):

Рисунок 2.1: Трехуровневая архитектура общения

Два иностранца обмениваются идеями, т.е., они общаются. Но это происходит виртуально. В реальности они меняются информацией со своим переводчиками, которые затем передают ее путем вибраций, издаваемых голосовыми связками. Или, если собеседники находятся на большом расстоянии друг от друга, переводчики передают информацию по телефону, и информация физически передается по телефонным линиям. Мы можем говорить и о виртуальном общении в горизонтальном направлении (философский разговор, общий язык переводчиков и электронные сигналы, передаваемые по телефонной линии) и реальном общении в вертикальном направлении (иностранец-переводчик и переводчик-телефон). Таким образом, мы можем выделить три уровня общения:

1. Между двумя иностранцами

2. Между переводчиками

3. Физическая передача информации с помощью средств коммуникации (телефонная линия, голос и т.д.)

Общение между иностранцами и переводчиками виртуально. Фактически, реальное общение происходит между иностранцем и его переводчиком.

В компьютерной сети используется больше уровней. Количество уровней зависит от выбранной вами системы сетевых протоколов. Система сетевых протоколов иногда называется сетевой моделью. Обычно вы работаете с системой, которая используется в Интернете и называется семейством TCP/IP. Помимо TCP/IP мы рассмотрим модель ISO OSI, стандартизированную ISO.

Рисунок 2.2: Сравнение сетевых моделей TCP/IP и ISO OSI

Семейство TCP/IP использует четыре уровня, в то время как ISO OSI использует семь. Системы TCP/IP и ISO OSI значительно отличаются друг от друга, хотя и похожи на сетевом и транспортном уровне.

Лишь в некоторых исключительных случаях, таких как SLIP или PPP, семейство TCP/IP работает на канальном и физическом уровне. Поэтому даже в Интернете мы используем протоколы канального и физического уровня модели ISO OSI.

3. Структура стандартов IEEE 802.X

В 1980 году в институте IEEE был организован комитет 802 по стандартизации локальных сетей, в результате работы которого было принято семейство стандартов IEEE 802-х, которые содержат рекомендации по проектированию нижних уровней локальных сетей. Позже результаты работы этого комитета легли в основу комплекса международных стандартов ISO 8802-1...5. Эти стандарты были созданы на основе очень распространенных фирменных стандартов сетей Ethernet, ArcNet и Token Ring.

Помимо IEEE в работе по стандартизации протоколов локальных сетей принимали участие и другие организации. Так, для сетей, работающих на оптоволокне, американским институтом по стандартизации ANSI был разработан стандарт FDDI, обеспечивающий скорость передачи данных 100 Мб/с. Работы по стандартизации протоколов ведутся также ассоциацией ЕСМА, которой приняты стандарты ЕСМА-80, 81, 82 для локальной сети типа Ethernet и впоследствии стандарты ЕСМА-89,90 по методу передачи маркера.

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

Специфика локальных сетей также нашла свое отражение в разделении канального уровня на два подуровня, которые часто называют также уровнями. Канальный уровень (Data Link Layer) делится в локальных сетях на два подуровня:

• логической передачи данных (Logical Link Control, LLC);

• управления доступом к среде (Media Access Control, MAC).

Уровень MAC появился из-за существования в локальных сетях разделяемой среды передачи данных. Именно этот уровень обеспечивает корректное совместное использование общей среды, предоставляя ее в соответствии с определенным алгоритмом в распоряжение той или иной станции сети. После того как доступ к среде получен, ею может пользоваться более высокий уровень - уровень LLC, организующий передачу логических единиц данных, кадров информации, с различным уровнем качества транспортных услуг. В современных локальных сетях получили распространение несколько протоколов уровня MAC, реализующих различные алгоритмы доступа к разделяемой среде. Эти протоколы полностью определяют специфику таких технологий, как Ethernet, Fast Ethernet, Gigabit Ethernet, Token Ring, FDDI, l00VG-AnyLAN.

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

Протоколы уровней MAC и LLC взаимно независимы - каждый протокол уровня MAC может применяться с любым протоколом уровня LLC, и наоборот.

Стандарты IEEE 802 имеют достаточно четкую структуру, приведенную на рис. 3.1:

Рис. 3.1. Структура стандартов IEEE 802.X

Эта структура появилась в результате большой работы, проведенной комитетом 802 по выделению в разных фирменных технологиях общих подходов и общих функций, а также согласованию стилей их описания. В результате канальный уровень был разделен на два упомянутых подуровня. Описание каждой технологии разделено на две части: описание уровня MAC и описание физического уровня. Как видно из рисунка, практически у каждой технологии единственному протоколу уровня MAC соответствует несколько вариантов протоколов физического уровня (на рисунке в целях экономии места приведены только технологии Ethernet и Token Ring, но все сказанное справедливо также и для остальных технологий, таких как ArcNet, FDDI, l00VG-AnyLAN).

Над канальным уровнем всех технологий изображен общий для них протокол LLC, поддерживающий несколько режимов работы, но независимый от выбора конкретной технологии. Стандарт LLC курирует подкомитет 802.2. Даже технологии, стандартизованные не в рамках комитета 802, ориентируются на использование протокола LLC, определенного стандартом 802.2, например протокол FDDI, стандартизованный ANSI.

Особняком стоят стандарты, разрабатываемые подкомитетом 802.1. Эти стандарты носят общий для всех технологий характер. В подкомитете 802.1 были разработаны общие определения локальных сетей и их свойств, определена связь трех уровней модели IEEE 802 с моделью OSI. Но наиболее практически важными являются стандарты 802.1, которые описывают взаимодействие между собой различных технологий, а также стандарты по построению более сложных сетей на основе базовых топологий. Эта группа стандартов носит общее название стандартов межсетевого взаимодействия (internetworking). Сюда входят такие важные стандарты, как стандарт 802. ID, описывающий логику работы моста/коммутатора, стандарт 802.1Н, определяющий работу транслирующего моста, который может без маршрутизатора объединять сети Ethernet и FDDI, Ethernet и Token Ring и т. п. Сегодня набор стандартов, разработанных подкомитетом 802.1, продолжает расти. Например, недавно он пополнился важным стандартом 802.1Q, определяющим способ построения виртуальных локальных сетей VLAN в сетях на основе коммутаторов.

Стандарты 802.3,802.4,802.5 и 802.12 описывают технологии локальных сетей, которые появились в результате улучшений фирменных технологий, легших в их основу. Так, основу стандарта 802.3 составила технология Ethernet, разработанная компаниями Digital, Intel и Xerox (или Ethernet DIX), стандарт 802.4 появился | как обобщение технологии ArcNet компании Datapoint Corporation, а стандарт 802.5 в основном соответствует технологии Token Ring компании IBM.

Исходные фирменные технологии и их модифицированные варианты - стандарты 802.х в ряде случаев долгие годы существовали параллельно. Например, технология ArcNet так до конца не была приведена в соответствие со стандартом 802.4 (теперь это делать поздно, так как где-то примерно с 1993 года производство оборудования ArcNet было свернуто). Расхождения между технологией Token Ring и стандартом 802.5 тоже периодически возникают, так как компания IBM регулярно вносит усовершенствования в свою технологию и комитет 802.5 отражает эти усовершенствования в стандарте с некоторым запозданием. Исключение составляет технология Ethernet. Последний фирменный стандарт Ethernet DIX был принят в 1980 году, и с тех пор никто больше не предпринимал попыток фирменного развития Ethernet. Все новшества в семействе технологий Ethernet вносятся только в результате принятия открытых стандартов комитетом 802.3.

Более поздние стандарты изначально разрабатывались не одной компанией, а группой заинтересованных компаний, а потом передавались в соответствующий подкомитет IEEE 802 для утверждения. Так произошло с технологиями Fast Ethernet, l00VG-AnyLAN, Gigabit Ethernet. Группа заинтересованных компаний образовывала сначала небольшое объединение, а затем по мере развития работ к нему присоединялись другие компании, так что процесс принятия стандарта носил открытый характер.

Сегодня комитет 802 включает следующий ряд подкомитетов, в который входят как уже упомянутые, так и некоторые другие:

• 802.1 - Internetworking - объединение сетей;

• 802.2 - Logical Link Control, LLC - управление логической передачей данных;

• 802.3 - Ethernet с методом доступа CSMA/CD;

• 802.4 - Token Bus LAN - локальные сети с методом доступа Token Bus;

• 802.5 - Token Ring LAN - локальные сети с методом доступа Token Ring;

• 802.6 - Metropolitan Area Network, MAN - сети мегаполисов;

• 802.7 - Broadband Technical Advisory Group - техническая консультационная группа по широкополосной передаче;

• 802,8 - Fiber Optic Technical Advisory Group - техническая консультационная группа по волоконно-оптическим сетям;

• 802.9 - Integrated Voice and data Networks - интегрированные сети передачи голоса и данных;

• 802.10 - Network Security - сетевая безопасность;

• 802.11 - Wireless Networks - беспроводные сети;

• 802.12 - Demand Priority Access LAN, l00VG-AnyLAN - локальные сети с методом доступа по требованию с приоритетами.

33 Программное обеспечение анализа и оптимизации сети

В последние годы появился новый тип (сетевого) программного обеспече­ния, призванный обеспечивать эффективную работу сетей ЭВМ.

Дело в том, что современные компьютерные сети тяготеют к глобализации и усложнению топологии, при этом (стихийно) развивающаяся сеть часто становится неэффективной (а иногда и неработоспособной) вследствие не­правильного выбора пропускных способностей и распределения потоков в сети; обычно деградация сети внешне (с точки зрения пользователя) проявля­ется в катастрофической задержке передачи сообщений (вплоть до полной блокировки сети).

Пожалуй, впервые указанные проблемы проявились в 70-х годах в связи с постройкой и эксплуатацией сети принадлежащего Министерству обороны США Управления перспективных исследований (DARPA), принятое назва­ние - сеть ARPANET; в настоящее время данная сеть считается прообразом глобальной сети InterNet.

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

ARPANET уже к 1975 году обеспечивала службу передачи сообщений между почти 100 ЭВМ, географически разнесенным по континентальной час­ти США и подключенных спутниковой связью (через Гавайи) к нескольким точкам в Европе, причем соединенные сетью ARPANET вычислительные машины во многих отношениях являлись несовместимыми друг с другом по аппаратному и программному обеспечению. Именно тогда был обеспечен сетевой доступ к мощнейшей для того времени ЭВМ ILLIAC IV и были ши­роко применены (с целью разгрузки вычислительных машин от выполнения задач обработки необходимых для функ1щонирования сети сообщений) вы­шеупомянутые IMP.

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

Заметим, что сети общего пользования сложной топологии с коммутацией пакетов появились не только в США (сети ARPANET и TELNET), но и в Ка­наде (DATAPAC), Англии (EPSS), Европе (EIN), Франции (TRANSPAC), Японии, Испании, Швеции и некоторых других странах.

В связи с проектированием и эксплуатацией сети ARPANET формулирова­лись и решались задачи анализа и проектировании сетей нескольких типов. Базовой задачей является анализ задержки - определение средней задержки передачи сообщения по заданному пути в сети (от конкретного источника к конкретному получателю сообщений). Конечным результатом является зави­симость задержки от интенсивности требований на обслуживание; обычно график этой зависимости имеет начальный малоизменяемый участок при изменении нагрузки от нуля до некоторой пороговой величины и экспонен­циально возрастает при нагрузке выше пороговой (соответствующей нагруз­ке насыщения сети), нагрузка насыщения сети соответствует блокировке се­ти по данному маршруту.

На рис.1 приведен типовой график данных расчета времени задержки, ясно видно пороговое значение нагрузки сети.

Рисунок 1 — Зависимость средней времени задержки сообщения (ордината) от нагрузки в сети (абсцисса) по результатам моделирования (слева) и упрощенная пороговая модель (справа).

На основе базовой задачи формулируются (более сложные) задачи рас­четов и оптимизации сети:

• Задача выбора пропускных способностей (т.н. ВПС-задача) - оптималь­ный (обычно по критерию стоимости сети) выбор пропускных способно­стей из конечного набора их возможных значений (при этом топология и потоки в сети считаются заданными).

• Задача распределения потоков (т.н. РП-задача) - фактически обратная вышеприведенной ВПС-задаче (заданными считаются пропускные спо­собности, а определяются потоки из условия минимизации средней за­держки).

• Задача выбора пропускных способностей и распределения потоков - {комбинированная ВПС/РП-задача) - минимизация стоимости сети при за­данной топологии и ограничениях на величину максимальной задержки.

При постановке задач используются несколько способов представления се­ти - географическая и логическая карты сети и структура сети (рис.2).

На левой части рис.3 показана достаточно общая структурная схема сети ЭВМ; при этом прямоугольниками представлены вычислительные средства выполнения задач обработки и хранения, соединенные друг с другом с по­мощью подсети связи (состоящей из коммутационных ЭВМ и высокоскоро­стных каналов передачи данных). Правая часть рис.3.5 иллюстрирует по­следний (перед этапом численного моделирования) этап представления топо­логии сети.

Рисунок 2 — Географическая (слева) и логическая карта сети ARPANET (со­стояние на июнь 1975 года).

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

Рисунок 3 — Общая структурная схема сети ЭВМ (слева) и используемая при моделировании структурная схема (справа).

Наиболее сложной задачей является задача выбора оптимальных (в соот­ветствие с определенным критерием оптимальности - обычно стоимости) па­раметров сети (в основном маршрутов передачи сообщений между узлами сети - при заданной топологии) при заданной максимальной средней задерж­ке (ВТПС/РП-задача); часто используют ВМУР {Вогнутый Метод Устране­ния Ребер) и МЗР (Метод Замены Ребер) - алгоритмы решения задачи.

Обычно предполагается, что 'хорошая' процедура выбора маршрута должна:

1. Обеспечивать быструю и надежную доставку сообщений.

2. Адаптироваться к изменениям топологии сети, происходящим в результате повреждений узлов и каналов.

3. Адаптироваться к меняющейся нагрузке между парами 'источник-получатель

4. Направлять пакеты в сторону от временно перегруженных узлов в сети.

5. Определять связность сети.

6. Допускать простое и автоматическое снятие и установку процессоров IMP.

Такую задачу можно решить лишь путем применения распределенного ал­горитма управления. Это значит, что не существует центра, который прини­мал бы обязательные для всей сети решения, все узлы выносят местные ре­шения относительно маршрутов динамическим образом. Основанное на по­добных предпосылках программное обеспечение было протестировано при­менительно к сети ARPANET; было показано, что процедура выбора мар­шрутов является в основном стабильной и приводит к очень хорошим ре­зультатам, в разумной степени реагирует на повреждения узлов и каналов сети, автоматически 'узнает' о появлении нового узла (как только он присое­диняется к сети или возвращается после исправления), эта особенность сети ARPANET является замечательной технической стороной данной сети. Заме­тим, что в дальнейшем многие из перечисленных разработок были использо­ваны в сети InterNet.

Таким образом, логично предположить, что в состав сетевого ПО (даже для ЭВМ уровня персонального компьютера) все чаще будут включаться ре­шающее вышеприведенные задачи программные компоненты. Например, для обслуживания баз данных фирмой Inprise Corp. в настоящее врет разраба­тывается эффективная технология выбора сервера с учетом загрузки процес­соров и сетевого трафика функционирующих в сети серверов, что позволит более равномерно распределять нагрузку между серверам!); в будущем они станут обязательными для системы распределенных вычислений (распреде­ленной ОС). Представляет интерес также разработанная для сети InterNet технология (и соответствующий протокол) MPLS (Multiprotocol Label Switch­ing - многопроцессорная коммутация с заменой меток), реализующая кон­цепции известной ATM-технологии в обобщенном виде (Asynchronous Trans­fer Mode - поддерживаемая консорциумом известных компаний технология, основанная на использовании упаковки разнородных типов данных в ячейки - 'cells' и создании функционирующих определенное время виртуальных со­единений в физическом канале связи с целью обеспечения гарантированной по времени доставки сообщений; в настоящее время ATN-технология счита­ется перспективной для транспортировки чувствительных к временной за­держке сообщений - например, цифровой телефонии, телевидения).

Тип сокета

Описание

SOCK_STREAM

Сокет будет использован для передачи данных через канал связи с использованием протокола TCP

SOCK_DGRAM

Передача данных будет выполняться без создания каналов связи через датаграммный протокол UDP

Код ошибки

Описание

WSANOTINITIALISED

Интерфейс Windows Sockets не был проинициализирован функцией WSAStartup

WSAENETDOWN

Сбой сетевого программного обеспечения

WSAEAFNOSUPPORT

Указан неправильный тип адреса

WSAEINPROGRESS

Выполняется блокирующая функция интерфейса Windows Sockets

WSAEMFILE

Израсходован весь запас свободных дескрипторов

WSAENOBUFS

Нет памяти для создания буфера

WSAEPROTONOSUPPORT

Указан неправильный протокол

WSAEPROTOTYPE

Указанный протокол несовместим с данным типом сокета

WSAESOCKTNOSUPPORT

Указанный тип сокета несовместим с данным типом адреса

Код ошибки

Описание

WSANOTINITIALISED

Перед использованием функции closesocket необходимо вызвать функцию WSAStartup

WSAENETDOWN

Сбой в сети

WSAENOTSOCK

Указанный в параметре дескриптор не является сокетом

WSAEINPROGRESS

Выполняется блокирующая функция интерфейсаWindows Sockets

WSAEINTR

Работа функции была отменена при помощи функции WSACancelBlockingCall

Код ошибки

Описание

WSANOTINITIALISED

Перед использованием функции необходимо вызвать функцию WSAStartup

WSAENETDOWN

Сбой в сети

WSAEADDRINUSE

Указанный адрес уже используется

WSAEFAULT

Значение параметра namelen меньше размера структуры sockaddr

WSAEINPROGRESS

Выполняется блокирующая функция интерфейсаWindows Sockets

WSAEAFNOSUPPORT

Этот протокол не может работать с указанным семейством адресов

WSAEINVAL

Сокет уже привязан к адресу

WSAENOBUFS

Установлено слишком много соединений

WSAENOTSOCK

Указанный в параметре дескриптор не является сокетом