Девять ошибок, которые могут помешать работе 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. Учитывая чужой негативный опыт, можно избежать многих ошибок, что позволит более грамотно и четко проектировать сети хранения данных.
