Интерактивные хранилища

Комментарий редактора. Нижеследующая заметка принадлежит перу Роба Мэллоу, менеджера европейского отделения компании Auspex Systems, занимающейся сетевым хранением данных. Он рассматривает различные способы хранения данных в сети.

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

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

Что действительно важно — это решение вопроса, как интегрировать масштабируемое, хорошо управляемое и надежное хранилище данных в вашу инфраструктуру, чтобы конечные пользователи (внутренние или внешние) могли рассчитывать на 100-процентную доступность данных в мире всегда работающего Internet. Эти ожидания появились как результат двух основных «сдвигов» в технологии, к которым должны быть готовы все организации, если они хотят избежать дорогостоящих ошибок.

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

Поставщики серверов, накопителей и сетевых устройств реализуют существенно разные конструктивные решения с целью использования преимуществ технологии параллельной обработки для непосредственно подключенных устройств (Direct Attached Storage, DAS), сетевых устройств хранения (Network Attached Storage, NAS) и сети хранения данных (Storage Area Network, SAN).

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

Модель DAS может считаться пригодной для работы компьютерных систем до их объединения в сеть, когда данные хранятся изолированно от других систем. DAS подходит для применения как с ПК начального уровня, так и с высокопроизводительными мэйнфреймами. Такой подход годится и для некоторых ресурсоемких приложений баз данных, где используется оперативная обработка транзакций (Online Transaction Processing , OTP).

NAS будет лучшим решением в системах UNIX и Windows NT для работы с общими файлами, совокупности файловых серверов, технических и научных приложений, Internet, некоторых типов приложений поддержки принятия решения.

Из-за недостатка в настоящее время стандартов, все конфигурации SAN представляют собой частные решения. Пока неясно, в какой мере они окажутся совместимы в будущем. Хотя в долгосрочной перспективе предполагается интероперабельность в гетерогенной среде серверов и устройств хранения данных, текущие приложения SAN все-таки рекомендуется реализовывать в гомогенном окружении, используя решения от одного поставщика, такого, как EMC, Hitachi Data Systems или Compaq Computer.

Модель SAN теоретически предусматривает все те же преимущества, что и архитектура NAS, однако применяемые на предприятии процедуры и средства управления следует все же определенным образом адаптировать. Последнее заставляет приверженцев этой технологии экспериментировать с тестовым развертыванием таких систем. SAN идеальна для приложений, где не требуется настоящее разделение данных, — вряд ли последняя возможность станет доступна раньше, чем стандарты на SAN достигнут уровня NAS. SAN также пригодна для приложений, где присущие Fibre Channel риски с точки зрения безопасности могут находиться под контролем и где можно избежать узких мест в производительности, вследствие заторов в узлах и каналах Fibre Channel.

Аналитики предсказывают снижение популярности моделей DAS и NAS в течение следующих пяти лет, хотя сегодня большинство предприятий еще используют их для хранения и доступа к файлам серверы общего назначения под UNIX и NT. Такой подход имеет множество недостатков с точки зрения производительности, масштабируемости и управляемости по сравнению со специализированными продуктами от таких поставщиков, как Network Appliance, EMC и Auspex Systems.

Высокоскоростное замедление

Комментарий редактора. Автор этой статьи Гэри Нортон является менеджером сервисной глобальной сети IBM. Он объясняет, как даже избыточные каналы глобальной сети могут не обеспечивать достаточную производительность.

Возможно ли, чтобы время отклика имело неприемлемые значения в слабо загруженном канале, где не возникает ошибок при передаче? Не торопитесь с ответом. Анализируя работу сети, особое внимание обратите на факт сброса пакетов.

Как правило, анализ работы сети начинается с определения загруженности. В соглашении с провайдером об уровне сервиса (Service Level Agreement, SLA) — или внутреннем SLA, если вы имеете свою собственную сеть, — должно быть указано, что в рабочее время средняя загрузка сети не должна превышать 60%. Такой уровень позволяет поддерживать пиковый трафик без чрезмерного резерва. Кратковременные заторы могут быть расчищены путем повторной пересылки пакетов на транспортном уровне с незначительными задержками в воспринимаемом времени отклика канала.

Программы-анализаторы собирают данные MIB от маршрутизаторов или коммутаторов сетей frame relay каждые 10 или 15 мин и сообщают среднюю загруженность за этот интервал времени. Емкость сети обычно рассчитана на трафик в часы пик, однако она определяется по усредненной нагрузке в наиболее занятые дневные часы в течение пяти рабочих дней. В результате сеть теоретически должна быть способна передавать все пакеты с первой попытки. Потери пакетов в каналах IP и постоянных виртуальных соединениях frame relay (Permanent Virtual Circuits, PVC) возможны вследствие двух причин: сброс (discard) и собственно потеря (drop).

Сброс — это фильтрация пакета на входе, еще до того, как он попадет в сеть. Это происходит, когда кратковременный наплыв пакетов переполняет буфер маршрутизатора или устройства доступа сетей frame relay (Frame Relay Access Device, FRAD), так что новые пакеты просто не могут войти. Потеря имеет место, когда пакет сам теряется где-то в сети. Обычно это случается, когда какой-либо из сетевых каналов вдоль пути пакета переполнен или в нем возникают ошибки.

Увидеть, что загрузка канала слишком высока, можно, наблюдая за числом сброшенных пакетов. Типичная сеть при 90% загрузки будет терять 2% пакетов, но это значение может меняться. Низкоскоростные каналы гораздо хуже управляются с неравномерной нагрузкой и часто сбрасывают пакеты уже при 80% загруженности.

То же самое относится и к ситуации, когда общая емкость проданных каналов больше реальной пропускной способности линии. Вместе с тем, в сетях frame relay наличие «мягкого сброса» приводит к тому, что очевидно сброшенный пакет тем не менее может быть отправлен. «Мягкий сброс» является механизмом frame relay для передачи данных по мере возможности, он использует непроданную «резервную» емкость для обслуживания трафика, когда его объем превышает заданный порог. Однако в любом случае транспортный протокол TCP передаст повторно те пакеты, которые не дошли до получателя. При доставке более 98% пакетов пользователь едва ли заметит ухудшение времени отклика, а сеансы не прервутся по тайм-ауту.

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

КРАСНЫЙ: сброс более 2% пакетов. Никаких новых приложений!

ЖЕЛТЫЙ: загрузка более 60%. Сеть следует модернизировать.

ЗЕЛЕНЫЙ: загрузка менее 60%. Допустимо развертывание новых приложений.

Возможно ли, чтобы канал работал с согласованным значением CIR в сетях frame relay или пиковой скоростью PCR в сетях ATM и при этом число сброшенных пакетов было велико? Да, возможно, и вот каким образом. Высокоскоростной порт, такой, как высокоскоростной последовательный интерфейс (High-Speed Serial Interface HSSI, стандарт ANSI, разработанный для пропускной способности до 53 Мбит/с), может легко перегрузить низкоскоростной канал. Отношение скорости порта к скорости канала должно быть менее, чем 10:1. Если низкоскоростной канал подключен к высокоскоростному порту, то он может стать причиной потери пакетов. Это происходит из-за того, что порт HSSI на 6 Мбит/с может легко загрузить 400 Кбайт в канал на 400 Кбит/с за полсекунды. В течение второй половины секунды коммутатор будет помечать любые последующие пакеты красным, и если мягкий сброс отключен, то он удалит пакеты из обращения. Данная проблема будет иметь место вне зависимости от того, насколько незначительным окажется трафик и низкой загруженность канала в остающиеся 899 секунд 15-ти минутного интервала сбора статистики.

Пакеты будут сброшены, и потребуется их повторная передача. Сброс пакетов всегда присущ сетям со взрывообразным характером трафика, однако пользователи заметят его последствия, когда будет сброшено более 2% пакетов.

Что же делать? Если это случилось с вами, не спешите модернизировать канал. В этом случае трата бюджетных средств — не лучший путь борьбы с длительным временем отклика. Есть два возможных решения: либо подключить канал к более медленному порту коммутатора, либо установить ограничение на скорость в маршрутизаторе, чтобы исключить любые попытки передать по каналу больше пакетов, чем это предусмотрено ограничениями.

И постоянно следите за доставкой пакетов.