Реконструкция систем хранения

23 августа 2004 LAN
LAN / Журнал сетевых решений
#7, июль 2004 г.

Вячеслав Ковалев
IT-эксперт
Открытые Технологии

Почему о необходимости перехода на новые архитектуры хранения данных стали задумываться именно теперь? Главная причина — в исторически сложившемся отставании возможностей систем хранения данных от потребностей инфраструктуры ИТ.

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


Напрямую не всегда хорошо

Даже поверхностное знакомство с инфраструктурой ИТ современного предприятия показывает, что в большинстве случаев решения для хранения данных создаются по принципу непосредственного подключения устройств хранения к серверу (Direct Attached Storage, DAS). Между тем устаревшая архитектура DAS не способна удовлетворить резко возросшие требования к дисковым устройствам со стороны современных приложений, в особенности тех, что работают на высокопроизводительных серверных системах (см. Рисунок 1). В этой связи остро встает вопрос о необходимости реконструкции систем хранения и переходе на новую, более емкую, производительную и масштабируемую архитектуру. Вместе с тем, большие объемы обрабатываемых данных представляют проблему и ввиду необходимости увеличения пропускной способности дисковых систем.

Архитектура с непосредственным подключения устройств хранения.


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

Архитектура "главный-подчиненный" (Master-Slave). Она базируется на принципе разграничения ролей устройств, подключенных к одной шине. В частности, шинные адаптеры (Host Bus Adapters, HBA) выполняют роль инициаторов запросов (Master) по отношению к конечным устройствам (Slave), в роли которых выступают устройства хранения данных. Характерным ограничением такой архитектуры является снижение скорости передачи данных при увеличении количества конечных устройств на одной шине. Чем ниже статус очередного устройства (он присваивается на этапе его конфигурирования и подключения), тем ниже и приоритет его доступа для захвата шины и последующей передачи данных.

Масштабирование. Архитектура параллельной шины SCSI позволяет подключить до i6 конечных устройств (дисков, НВА). В целях расширения адресного пространства применяется адресация логических устройств (Logic Unit Number, LUN). Однако и здесь не обходится без специфических ограничений. Чем больше конечных физических устройств подключается к шине, тем вероятнее присвоение очередному устройству более низкого приоритета доступа к шине. При высоких требованиях к масштабированию современных систем хранения необходимо заранее продумать схемы подключения последующих устройств, что, по понятным причинам, трудно прогнозируемо. Другая очевидная проблема также напрямую связана с адресацией — это жесткая схема присвоения имен в рамках одной шины SCSI по принципу bus-target-device/LUN. Отсутствие свободы выбора в присвоении устройству имени препятствует организации доступа к одному устройству со стороны нескольких серверов, даже если их подключить к соответствующей шине SCSI. Этот фактор необходимо учитывать на этапе реконструкции при проведении работ по масштабированию и объединению систем в единый кластерный комплекс.

Доступность данных. Требования доступности и катастрофоустойчивости все чаще выдвигаются на первый план. Однако и здесь возникают проблемы, которые в рамках старой архитектуры шин SCSI решить невозможно. В чем они проявляются? Изначально соединения SCSI были рассчитаны на подключение устройств в пределах одной серверной комнаты в силу существующих ограничений на предельную длину кабеля SCSI, и, как правило, дополнительная защита данных обеспечивалась их резервным копированием на ленточные устройства. Этого было достаточно, пока вопрос обеспечения доступности данных не стал слишком важным для деятельности компаний и предприятий. Его можно было решить только путем объединения в единую сеть распределенных систем хранения, находящихся за рамками одной комнаты, одного здания, одного региона и т. д. Шина SCSI выступает главным сдерживающим фактором при решении вопросов надежного хранения данных.

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


Семь раз отмерь

Как правильно найти верное и оптимальное для конкретного случая решение? Очевидно, что для этого потребуется провести предварительный анализ, который позволит рассчитать объем необходимых инвестиций для максимального соблюдения требований со стороны приложений. Подобный анализ наиболее нагляден, когда данные собраны в виде таблицы, где, во-первых, отражены все нужные приложения, а во-вторых — выдвигаемые с их стороны условия. В Таблице 1 определены основные требования к системам хранения, на основе которых в дальнейшем будет выбираться архитектурное решение.


 
"Золото"
"Серебро"
"Бронза"
Скорость передачи > 80 Мбайт/c 40-80 Мбайт/c < 40 Мбайт/c
Резервирование данных Полное копирование еженедельно.
Инкрементальное копирование каждые 6 ч
Полное копирование еженедельно.
Инкрементальное копирование каждые 12 ч
Полное копирование еженедельно.
Инкрементальное копирование каждые 24 ч
Время хранения данных 6 лет 1 год 3 мес
Максимальный простой системы < 5 мин 5-10 мин > 10 мин
Защита от сбоев RAID 10 RAID 5 Нет
Стоимость владения
(1 год)
> 1 доллара/1 Гбайт 0,5-1 доллар/1 Гбайт < 0,5 долларов/1 Гбайт

Таблица 1. Различные уровни систем хранения.


Системы хранения данных разобъем на базовые группы и назовем их условно "золотая", "серебряная", "бронзовая". Принятая терминология отражает возможный уровень эксплутационных затрат, а он, в свою очередь, определяет стоимость владения системой (Total Cost of Ownership, TCO). Как показала практика, подобный подход позволяет взглянуть на имеющиеся у предприятия многочисленные системы хранения более дифференцированно и разделить их не только по качественным и количественным характеристикам, но и в соответствии с той ролью, которую они будут выполнять в структуре предприятия после реконструкции. Такая классификация поможет сделать правильный выбор при проведении работ по реконструкции систем хранения данных. Правда, в этой связи возникает закономерный вопрос: что же должен обеспечивать тот или иной уровень?

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

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

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

В Таблице 1 представлены ориентировочные значения ТСО, в каждом конкретном случае они могут быть иными, на что влияют следующие обстоятельства:

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

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

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


Каждому по потребности

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


Требования
Приложение
 
Файловый доступ
Электронная почта
CRM
Биллинг
ERP
Объем хранимых данных
0,5-1 Тбайт
< 500 Гбайт
< 500 Гбайт
0,5-1 Тбайт
0,5-1 Тбайт
Наличие зеркала
Нет
Да
Да
Да
Да
Скорость доступа
Нет
Нет
Да
Да
Да
Резервирование в оперативном режиме
Нет
Да
Да
Да
Да
Тиражирование на удаленную площадку
Нет
Нет
Нет
Нет
Да
Уровень систем хранения данных
"Бронза"
"Серебро"
"Серебро"
"Золото"
"Золото"

Таблица 2. Различные уровни систем хранения.


В качестве иллюстрации остановимся подробнее на некоторых позициях таблицы. Так, системы хранения данных для поддержки приложений планирования корпоративных ресурсов (Enterprise Resource Planning, ERP) отнесены к "золотому" уровню, и большое значение придается привлечению технологии тиражирования данных на альтернативную площадку. Чем это вызвано?

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

"Золотому" уровню наиболее полно соответствует архитектура сети хранения SAN. Благодаря применению Fibre Channel и IP, а также технологии виртуализации гетерогенных устройств от разных производителей, архитектура SAN в состоянии обеспечить требуемые показатели надежности, скорости передачи, защиты и резервирования данных. Кроме того, SAN предоставляет возможность тиражирования данных в резервный центр и предлагает большой выбор различных средств и способов тиражирования.

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

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

Архитектурное решение на базе SAN для поддержки высококритичных приложений.


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

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

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

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


Когда начинать реконструкцию

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

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

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

Представленный здесь список минимален и может быть расширен, однако сути это не меняет и дополнительные факторы будут являться лишь дополнением.


Новая архитектура - новые требования

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

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

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

По сути, эти устанавливаемые на серверные платформы программные пакеты — прежде всего речь идет о втором типе средств — выполняют три основные функции.

  • Мониторинг. В отношении систем хранения данных мониторинг позволяет собирать и обрабатывать статистику операций ввода/вывода. На этапе реконструкции и внедрения новой архитектуры важно своевременно провести анализ производительности на уровне каждого сервера и, если она окажется недостаточной, оперативно принять необходимые меры.
  • Автоматизация. Ее внедрение позволяет исключить субъективный фактор при работе с системами хранения данных. Особенно это относится к виртуализации большого объема дискового пространства, которая неосуществима без специальных средств автоматизации работы систем RAID, виртуальных томов, виртуальных дисков, устройств коммутации и балансировки каналов доступа и передачи данных и т. и. Возможности автоматизации могут использоваться, в частности, для обнаружения новых дисков, опознания их типов и дальнейшего конфигурирования с соблюдением правил доступа в пределах соответствующих зон.
  • Протоколирование. Данная функция востребована на заключительном этапе реконструкции систем хранения данных и используется в продолжение всего последующего периода их эксплуатации. Ее основная роль -поддержание в актуальном состоянии конфигурации задействованных систем хранения данных. В ряде случаев она может пригодиться при проведении отладочных и восстановительных работ.

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

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


Заключение

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

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

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

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




Предыдущая новость:
Год десятый. Он же год первый
Следующая новость:
Составление IT-бюджета