headermask image

Notice: Undefined variable: t in /var/www/user97185/data/www/system-administrators.info/yandex-ad.php on line 15

Notice: Undefined variable: r in /var/www/user97185/data/www/system-administrators.info/yandex-ad.php on line 15
Рекомендую: Фриланс-биржа | Кэшбэк-сервис | Интернет-бухгалтерия

Средство против «сетевой слепоты»

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

Многие предприятия добиваются значительной экономии при помощи сетей хранения данных (Storage Area Networks, SAN), которые благодаря масштабируемой емкости хранения, высокой готовности и производительности облегчают предоставление массовых хранилищ в крупных вычислительных центрах и управление ими. Однако увеличение емкости, рост скорости передачи данных, гетерогенное оборудование от разных производителей и технологии виртуализации делают мониторинг структуры сетей хранения данных и анализ внутренних процессов все более сложным.

То, что подобные сложные инфраструктуры SAN способствуют устранению проблемы с недостаточной емкостью, сомнений не вызывает. Но для сетевого администратора они порождают новые трудности, которые на профессиональном жаргоне называются «сетевой слепотой». Под этим имеется в виду невозможность диагностировать, анализировать и предотвратить отказы, а кроме того, сложные протоколы и структуры снижают производительность сети. Преодоление «слепоты» имеет важное практическое значение. Согласно отчету компании Infostor, опубликованному в 2006 году, более половины всех компаний рискуют понести значительный ущерб уже в первые четыре часа после отказа, причем убыток предприятий, специализирующихся на посылочной торговле, достигает сотен тысяч долларов, а магазины электронной торговли и финансовые учреждения теряют около 6,4 млн долларов в час. Эти цифры еще раз убеждают в том, что необходимо очень быстро реагировать на отказы и проблемы с производительностью.

Для распознавания и устранения возникающих проблем в первую очередь необходимо определить, что же произошло, как это случилось и — что, пожалуй, сложнее всего — где скрывается ошибка. При этом администраторам нередко приходится полагаться на инструменты для управления ресурсами хранения (Storage Resource Management, SRM) и инструменты управления, предназначенные для конкретных устройств. Все они, конечно, могут идентифицировать проблемы с конфигурацией и отказы соединений, а также дать сводную информацию о параметрах пропускной способности и частоте ошибок. Однако данные о производительности сети хранения и частоте ошибок не связаны с приложениями и их потребностью в дисковом пространстве; кроме того, их недостаточно для измерения времени, необходимого для выполнения определенных операций ввода/вывода.

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

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

Как устранить проблемы быстро?

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

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

Производители инструментов для анализа реагируют на предъявляемые требования выпуском новых продуктов: точки анализа трафика (Traffic Analysis Point, TAP) компании Finisar, к примеру, интегрируются непосредственно в структуру SAN и позволяют контролировать сети хранения (см. Рисунок 1). При помощи оптических переключателей (сплиттеров) TAP пассивно копирует все данные без прерывания потока данных и дополнительных задержек. Поскольку они работают на оптическом уровне, TAP, по данным Finisar, совместимы с оборудованием любых производителей.
034_133465632424.gif
В то время как ТАР обеспечивают не предусматривающий вмешательства доступ к сети хранения, зонды следят за соединениями сети хранения, проходящими через ТАР, со скоростью линии до 4 Гбит/с. Так, к примеру, ProbeFCX того же производителя может просматривать до восьми двунаправленных соединений SAN и одновременно выявлять различные происшествия и отказы в локальной сети, а также измерять параметры производительности, благодаря чему «сетевая слепота» исчезает. Регистрируемые при этом события можно использовать для запуска процесса записи трафика при помощи протокольного анализатора и соответствующего программного обеспечения. ПО Netwisdom, к примеру, осуществляет фундаментальную проверку пакетов данных, протокольный анализ и экспертную диагностику, поэтому ошибки быстро блокируются и проблема оперативно устраняется.

Посредством SNMP программное обеспечение ProbeV семейства NetWisdom получает от коммутаторов важные параметры производительности и распространяет функцию мониторинга на всю коммутирующую инфраструктуру сети хранения данных. Различное программное обеспечение помогает администраторам отслеживать ошибки и параметры производительности во всей сети SAN, причем при переходе на другие устройства и структуры осуществляется точная корреляция трафика. Выявление проблем происходит при помощи анализа пакетов и всеобъемлющих механизмов поиска, которые способны быстро проверить данные для проведения точной диагностики отказов. А затем системные администраторы могут без промедления определить, где и почему произошла ошибка, после чего ее остается только устранить. Предотвратить появление ошибок и обеспечить оптимизацию удается с помощью непрерывного сетевого мониторинга, который позволяет установить, насколько эффективно и надежно работает сеть хранения данных в типичных и нетипичных условиях.

Предотвращение «сетевой слепоты»

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

С введением технологии «блуждания» (roving), применение которой расширяет возможности просмотра зондов ситуация меняется принципиально. «Блуждание» комбинирует высокоразвитую функциональность коммутации на физическом уровне с технологией выборки. Таким образом, при наличии одного-единственного зонда удается вести мониторинг 144 соединений SAN посредством TAP (см. Рисунок 2). С увеличением количества отслеживаемых одним зондом соединений SAN системы центров обработки данных получают возможность не ограничиваться лишь определенными критическими соединениями инфраструктуры, а распространить их на всю SAN, обеспечивая глубокий анализ и мониторинг сети хранения данных. В результате администраторы могут задавать граничные значения производительности для каждого отдельного соединения в реальном времени, чтобы при необходимости получать подробную информацию и предотвращать возможные проблемы.
034_23435345563346.gif
Поскольку мониторинг каждой группы соединений SAN проводится в определенные интервалы времени, опрос важных для работы соединений может выполняться чаще, в то время как до соединений SAN второго и третьего порядка очередь доходит лишь один или два раза в день. Таким образом, можно изменять интенсивность мониторинга в зависимости от важности информации и приложений, а значит, приобретенные зонды могут использоваться в более обширных областях сети хранения данных.

ЗАКЛЮЧЕНИЕ

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

Кристина Мерсьер — технический специалист по сетям хранения данных в компании Finisar Corporation.
Взято с Lan