Logo    
Деловая газета CitCity.ru CITKIT.ru - все об Open Source Форумы Все публикации Учебный центр Курилка
CitForum    CITForum на CD    Подписка на новости портала Море(!) аналитической информации! :: CITFORUM.RU
IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

29.05.2017

Google
WWW CITForum.ru
С Новым годом!

2004 г.

Девять ошибок, которые могут помешать работе SAN

Денис Сенин, инженер-дизайнер МКСК
«Экспресс-Электроника» #8(117)/2004

Сети хранения данных или, как их принято называть, Storage Area Network (SAN), призваны удовлетворять индивидуальные потребности пользователей в хранении информации. Объясняется это двумя причинами. Прежде всего, SAN ориентирована на решение какой-то определенной задачи. Кроме того, сети хранения данных по стоимости являются одними из самых дорогостоящих систем. Поэтому при внедрении SAN в информационную инфраструктуру предприятия заказчик должен быть уверен, что данная сеть максимально соответствует поставленной задаче, а имеющиеся ресурсы используются наиболее эффективно. Для того чтобы достичь этого, необходимо грамотно спроектировать SAN. Допущенные при проектировании ошибки могут сильно повлиять на эффективность работы системы и даже свести к нулю все усилия и затраты на ее разработку.

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

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

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

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

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

В-третьих, не стоит забывать, что SAN является аппаратно-программным комплексом. Можно, конечно, рассматривать сеть хранения данных как исключительно аппаратное решение. Однако такая реализация SAN используется крайне редко. Следует помнить: SAN будет работать с определенными операционными системами, а потому необходимо учитывать особенности работы этих ОС. SAN не может существовать отдельно от операционных систем, ведь последние являются непосредственными потребителями ее сервисов и ресурсов. Поэтому будет ошибочным начинать проектирование сети хранения данных без учета особенностей ее взаимодействия с ОС. В качестве примера рассмотрим следующую схему SAN. На рис. 1 изображена система SAN, разработанная специально для телекомпании с целью обеспечения непрерывного быстрого доступа к файлам видеомонтажа, видеоархива и телеэфира. На первый взгляд, схема выглядит логичной и не вызывает никаких нареканий. Станции видеомонтажа и телеэфира имеют непосредственный доступ к одним и тем же дискам хранилища благодаря использованию технологии Fibre Channel. Однако в данном случае в расчет не принималась операционная система, которая установлена на этих станциях, что делает невозможным применение данного решения в среде MS Windows. Особенности работы MS Windows с жесткими дисками не позволяют обеспечивать одновременный доступ двух и более серверов или рабочих станций к одному диску. Объединение станций в отказоустойчивый кластер также невозможно, поскольку программное обеспечение для видеомонтажа и обеспечения телеэфира не работает в этой среде. В окружении ОС Unix такое решение тоже было бы реализовано не полностью, так как одна из станций могла бы осуществлять функции чтения и записи данных с диска, в то время как остальные лишь считывали бы информацию. В данном случае были рассмотрены только штатные средства операционных систем MS Windows и Unix. При условии использования дополнительного программного обеспечения такая схема, конечно же, имеет право на жизнь. Однако специальное ПО, позволяющее нескольким рабочим станциям или серверам получать одновременный доступ к одному диску, стоит достаточно дорого и, кроме того, требует дополнительных выделенных вычислительных ресурсов.

Четвертой широко распространенной ошибкой является неправильное определение дискового пространства. Известно, что дисковые системы имеют так называемые «грязный» и «чистый» объемы. «Грязный» объем определяется путем умножения общего количества дисков на объем каждого из них, а «чистый» объем – это дисковое пространство, доступное для использования — без учета резервных дисков и дисков, применяемых для обеспечения избыточности в RAID-массивах. Часто за требуемый заказчику объем выдается общее дисковое пространство, что впоследствии вызывает у клиента вполне закономерный вопрос: почему объем доступного пространства на 30% меньше того, который он заказывал?

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

Шестая ошибка, заключающаяся в неправильном выборе дисковых накопителей, может легко погубить любую хорошую сеть хранения данных. Важными параметрами дисковых накопителей для SAN являются объем, скорость вращения шпинделей и время доступа. Если единственный вопрос, связанный с объемом диска, это то, как им правильно распорядиться, то скорость вращения шпинделей и время доступа влияют на производительность системы в гораздо большей степени. Так, например, для систем, работающих с большим количеством запросов, необходимо подбирать быстрые диски с малым временем отклика. Лучше использовать большее количество дисков меньшего объема, но с максимальной скоростью вращения шпинделя, чем меньшее количество дисков большего объема. Для потоковых систем требование, предъявляемое к скорости вращения шпинделей, напротив, не является критичным, поскольку в таких системах намного важнее правильно распорядиться существующими объемами. Это можно сделать, подобрав нужную организацию RAID-массива или используя системы, реализующие технологию виртуализации дискового пространства. Тип диска также имеет значение. Так, для систем, на которые ложится основная нагрузка, рекомендуется подбирать диски с интерфейсами SCSI или Fibre Channel. Попытка сэкономить на таких дисках, использовав вместо них недорогие ATA-диски, может привести к частым сбоям, связанным с выходом дисков из строя. Объясняется это тем, что диски с интерфейсом ATA не рассчитаны на длительную эксплуатацию в режиме максимальной нагрузки, а ориентированы в большей степени на домашние или офисные рабочие станции, где их загрузка не постоянна и редко достигает максимального уровня. Поэтому ATA-диски больше подходят для архивов, временных хранилищ, NAS-серверов или дисковых ресурсов файловых серверов. Использование же дисков с интерфейсами SCSI или Fibre Channel в архивных системах или временных хранилищах нецелесообразно из-за их относительно высокой стоимости. К вопросу выбора дисков для систем, реализующих технологию виртуализации дискового пространства, также необходимо подходить очень внимательно. Несмотря на заявления производителей о том, что различные параметры дисков не влияют на производительность системы в целом, лучше все же следовать общим правилам для дисковых систем: желательно, чтобы все диски в одной системе были одинаковыми.

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

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

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

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

Размещение рекламы — тел. +7 495 4119920, ICQ 232284597

Подписка на новости IT-портала CITForum.ru
(библиотека, CITKIT.ru, CitCity)

Новые публикации:

24 декабря

CITKIT.ru:

  • Новогодние поздравления
  • Сергей Кузнецов. Цикл Операционные системы: Ностальгия по будущему:

  • Алексей Федорчук. OpenSolaris 2008.11 Release

  • Сергей Голубев:

  • Евгений Чайкин aka StraNNik (Блогометки):

    17 декабря

  • С.Д.Кузнецов. Базы данных. Вводный курс

    10 декабря

    CITKIT.ru:

  • OpenSolaris 2008.11 Release

  • Альтернативные ОС: две грустные истории (С.Кузнецов)
  • Nokia N810 — доведение до ума
  • CitCity:

  • Платформа 2009: заоблачные перспективы Microsoft

    4 декабря

  • Лекция С.Д.Кузнецова Понятие модели данных. Обзор разновидностей моделей данных

    CITKIT.ru:

  • OpenSolaris 2008.11 Release. Первые впечатления

  • Linux vs FreeBSD: продолжим "Священные войны"?

  • Nokia N810 as is

  • Индульгенция для FOSS

  • Друзья СПО'2008

    26 ноября

  • Нечеткое сравнение коллекций: семантический и алгоритмический аспекты

    CitCity:

    CITKIT.ru:

  • Глава из книги А.Федорчука
    Сага о FreeBSD:
  • 19 ноября

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

  • Язык модификации данных формата XML функциональными методами

    CITKIT.ru:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:

    Заметки к книге:

  • FreeBSD: монтирование сменных устройств и механизм HAL
  • Текстовый редактор ee

    12 ноября

  • Правило пяти минут двадцать лет спустя, и как флэш-память изменяет правила (Гоц Грейф, перевод: Сергей Кузнецов)

    CITKIT.ru:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:
  • OSS в России: взгляд правоведа (В.Житомирский)

  • Новая статья из цикла С.Голубева "Железный марш":

    29 октября

  • О некоторых задачах обратной инженерии

  • Веб-сервисы и Ruby

  • Тестирование web-приложений с помощью Ruby

    CITKIT.ru:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:

  • PuppyRus Linux - беседа с разработчиком (С.Голубев)

  • Сергей Кузнецов. Заметка не про Linux

    22 октября

  • Обзор методов описания встраиваемой аппаратуры и построения инструментария кросс-разработки

    CITKIT.ru:

  • Сергей Кузнецов. Почему я равнодушен к Linux

  • Глава из книги А.Федорчука
    Сага о FreeBSD:
  • Что надо иметь
    3. Базовые познания

    CitCity:

  • Управление IT-инфраструктурой на основе продуктов Microsoft

    15 октября

  • Методы бикластеризации для анализа интернет-данных

    CitCity:

  • Разъемы на ноутбуках: что они дают и зачем их так много?
  • AMD Puma и Intel Centrino 2: кто лучше?

    CITKIT.ru:

  • Новый цикл статей С.Голубева
    Железный марш:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:

    8 октября

  • Автоматизация тестирования web-приложений, основанных на скриптовых языках
  • Опыт применения технологии Azov для тестирования библиотеки Qt3

    Обзоры журнала Computer:

  • SOA с гарантией качества
  • Пикоджоуль ватт бережет
  • ICT и всемирное развитие

    CitCity:

  • Пиррова победа корпорации Microsoft

    CITKIT.ru:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:

    Статья из архива:

  • Я живу в FreeBSD (Вадим Колонцов)

    Новые Блогометки:

  • Перекройка шаблона Blogger или N шагов к настоящему
  • Blogger. Comment style
  • Screenie или глянцевый снимок экрана

    2 октября

    CITKIT.ru:

  • Сага о FreeBSD (А. Федорчук)

    Zenwalk: пакет недели

  • Банинг — интеллектуальное развлечение (С.Голубев)

    CitCity:

    25 сентября

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

    CITKIT.ru:

  • Пользователям просьба не беспокоиться... (В.Попов)

  • Снова про ZFS: диск хорошо, а два лучше
  • Командная оболочка tcsh (А.Федорчук)

    Zenwalk: пакет недели

    17 сентября

  • T2C: технология автоматизированной разработки тестов базовой функциональности программных интерфейсов
  • Технология Azov автоматизации массового создания тестов работоспособности

    CITKIT.ru:

  • FreeBSD: ZFS vs UFS, и обе-две — против всех (А.Федорчук)

    Zenwalk: пакет недели

  • Дачнет — практика без теории (С.Голубев)

    10 сентября

  • За чем следить и чем управлять при работе приложений с Oracle
  • Планировщик заданий в Oracle
    (В.Пржиялковский)

    CITKIT.ru:

  • Microsoft: ответный "боян" (С.Голубев)

  • Причуды симбиоза, или снова "сделай сам" (В.Попов)

  • Файловые системы современного Linux'а: последнее тестирование
  • Zsh. Введение и обзор возможностей
    (А.Федорчук)

    Описания пакетов Zenwalk: Zsh, Thunar, Thunar-bulk-rename, Xfce4-places-plugin, Xfce4-fsguard-plugin

    Блогометки:

  • Google Chrome
  • Лончер для ASUS Eee PC 701

    3 сентября

    CITKIT.ru:

  • Заметки о ядре (А.Федорчук):

    Добавлены описания пакетов Zenwalk: Galculator, Screenshot, Gnumeric, Pidgin

    В дискуссинном клубе:

  • И еще о Википедии и Google Knol

  • Лекция для начинающего линуксоида (С.Голубев)

    26 августа

  • Транзакционная память (Пересказ: С. Кузнецов)

    CITKIT.ru:

  • Открыт новый проект Zenwalk: пакет недели

  • Статья Текстовые процессоры и их быстродействие: конец еще одной легенды?

    21 августа

    CITKIT.ru:

  • Почему школам следует использовать только свободные программы (Ричард Столлман)
  • Беседа Сергея Голубева с учителем В.В.Михайловым

  • Википедия или Гуглезнание? Приглашение к обсуждению (Алексей Федорчук)
  • Народная энциклопедия от Google (StraNNik)

  • Обзор Mandriva 2009.0 Beta 1 Thornicrofti
  • Новичок в Линукс: Оптимизируем Mandriva 2008.1

  • Книга Zenwalk. Приобщение к Linux:

    13 августа

    CitCity:

  • Мирный Atom на службе человеку. Обзор платы Intel D945GCLF с интегрированным процессором
  • Обзор процессоров Intel Atom 230 на ядре Diamondville

  • iPhone - год спустя. Скоро и в России?

    CITKIT.ru:

  • Интермедия 3.4. GRUB: установка и настройка (из книги Zenwalk. Приобщение к Linux)

    6 августа

  • СУБД с хранением данных по столбцами и по строкам: насколько они отличаются в действительности? (Пересказ: С. Кузнецов)

    CITKIT.ru:

  • Интермедия 2.2. Что неплохо знать для начала (из книги Zenwalk. Приобщение к Linux)

  • И снова про шрифты в Иксах (А.Федорчук)

  • 20 самых быстрых и простых оконных менеджеров для Linux

  • Дело о трех миллиардах (С.Голубев)

    30 июля

  • OLTP в Зазеркалье (Пересказ: С. Кузнецов)

    CitCity:

  • Будущее BI в облаках?
  • Тиражные приложения и заказная разработка. Преимущества для заказчика
  • Дискуссия со сторонниками заказной разработки

    CITKIT.ru:

  • Новые главы книги Zenwalk. Приобщение к Linux:
  • Глава 8. Пакеты: средства установки, системы управления, системы построения
  • Глава 9. Zenwalk: репозитории, пакеты, методы установки

    23 июля

    CITKIT.ru:

  • Все против всех. 64 vs 32, Intel vs AMD, tmpfs vs ext3
  • Две головы от Intel

  • Zenwalk: обзор штатных приложений (глава из книги "Zenwalk. Приобщение к Linux")

  • Нормально, Григорий...

    16 июля

    Обзоры журнала Computer:

  • Перспективы и проблемы программной инженерии в XXI веке
  • Большие хлопоты с большими объемами данных
  • Перспективы наноэлектроники

    CITKIT.ru:

  • Интермедия о лицензиях (А.Федорчук. "Zenwalk. Приобщение к Linux")

  • Есть ли будущее у KDE?

  • Linux в школе: альтернативный вариант в задачах

  • Шифр (приключения агента Никодима)

    10 июля

    CITKIT.ru:

  • Новые разделы книги А. Федорчука Zenwalk. Приобщение к Linux:
  • Интермедия вступительная. Linux или GNU/Linux? Как вас теперь называть?
  • Глава 5. Среда Xfce
  • Глава 6. Xfce: приложения и плагины

  • ZUR (Zenwalk User Repository) FAQ

    2 июля

  • Персистентность данных в объектно-ориентированных приложениях (С. Кузнецов)

    CITKIT.ru:

  • Новые разделы книги А. Федорчука Zenwalk. Приобщение к Linux:
  • Интермедия 1.2. Дорога к Zenwalk'у. Период бури и натиска
  • Интермедия 3.3. Немного о Linux'е и "железе"
  • Глава 4. Настройка: инструментами и руками
  • Интермедия 4.1. Zenpanel и конфиги: поиски корреляции

  • Интервью с Жан-Филиппом Гийоменом, создателем дистрибутива Zenwalk

  • Linux в школе: первые итоги (С. Голубев)

    25 июня

    CITKIT.ru:

  • Zenwalk. Приобщение к Linux (А. Федорчук)

  • Логика и риторика (С.Голубев)

  • Технология Tru64 AdvFS

  • Ханс Райзер предлагает отвести полицейских к телу Нины

    18 июня

  • Проекты по управлению данными в Google (Пересказ: С. Кузнецов)

    CITKIT.ru:

  • ОС и поддержка "железа": мифы и реальность (А. Федорчук)

  • Linux в школе: другие дистрибутивы

  • Пинок (С. Голубев)

    4 июня

  • Ландшафт области управления данными: аналитический обзор (С. Кузнецов)

    CITKIT.ru:

  • Linux в школе: слово заинтересованным лицам

  • SlackBuild: пакеты своими руками

  • Linux от компании Novell. Установка и обзор openSUSE Linux

    Все публикации >>>




  • IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

    Информация для рекламодателей PR-акции, размещение рекламы — тел. +7 495 4119920, ICQ 232284597 Пресс-релизы — pr@citcity.ru
    Послать комментарий
    Информация для авторов
    Rambler's Top100 TopList liveinternet.ru: показано число просмотров за 24 часа, посетителей за 24 часа и за сегодня This Web server launched on February 24, 1997
    Copyright © 1997-2000 CIT, © 2001-2007 CIT Forum
    Внимание! Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав. Подробнее...