Планирование системы хранения данных (SAN)

Данный раздел пополняется силами модераторов и постоянных посетителей.

Модераторы: Trinity admin`s, Free-lance moderator`s

Ответить
Аватара пользователя
gs
Сотрудник Тринити
Сотрудник Тринити
Сообщения: 16650
Зарегистрирован: 23 авг 2002, 17:34
Откуда: Москва
Контактная информация:

Планирование системы хранения данных (SAN)

Сообщение gs » 08 авг 2006, 14:04

Нам постоянно задают вопросы - какая дисковая система подойдет. Сказать навскидку очень сложно и приходится задавать кучу наводящих вопросов. Поэтому основные моменты изложу тут.

Для начала лирическое отступление. Помните фильм "Свидание вслепую"? Там есть момент на суде:
- А где его адвокат?
- Он хочет защищать себя сам.
- Тогда он нескоро выйдет.

А теперь к делу.

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

Это не в порядке убывания - все эти моменты принципиально важны.


По части производительности надо определить текущую нагрузку на систему и ее рост в ближайшее обозримое время.
Стоит отметить, что для разных задач производительность зависит от разных вещей – например для СУБД в основном числом шпинделей и в несколько меньшей степени размером кэша и мощностью контроллеров, для видеосерверов – в основном мощностью контроллеров и в меньшей степени числом шпинделей (хотя оно тоже важно, если будет работа с десятками-сотнями потоков).
Для этого рекомендую воспользоваться небезызвестной утилитой perfmon.exe и промониторить следующие параметры: phisical disk - reads/sec, writes/sec, read bytes/sec, write bytes/sec, average/current queue lenght.
Снимать нагрузку надо достаточно продолжительное время, чтобы в графики попали как средние, так и пиковые значения (обычно достаточно рабочего дня - но зависит от ситуации). Если в Вашей компании есть периоды повышенной активности, то надо посмотреть и их. Тут есть еще один момент. Планирование системы исходя из пиковых параметров может вылиться в немалые деньги, поэтому Вам надо решить - платить или примириться с временными тормозами.
Если планируется подключение нескольких серверов, соответственно мониторить надо все.
По этим цифрам определяется потребное число шпинделей, уровень рэйд, распределение дисков по группам и мощность контроллеров. Интерпретация этих цифр - на совести интегратора, самому разобраться трудно. Причем готовьтесь к дополнительным наводящим вопросам.
Предостерегаю от крайностей – например бессмысленно использовать мощную систему с одной полкой дисков (если нет особых соображений типа функционала или масштабирования). И наоборот, не стоит надеяться, что для мощной СУБД подойдет система начального уровня, набитая полусотней дисков – не потянут контроллеры, мало кэша, да и тупые они.


Логическая организация массива.
Тут надо расписать все задачи, которые лягут на систему. Из этого определяется схема организации логических томов на дисковой системе и приходящаяся на них нагрузка (см. пункт выше). Под тяжелые задачи необходимо выделять отдельные дисковые группы, а всякую мелочь можно сложить на одну группу, порезав ее на луны (LUN). Уровень рэйд определяется исходя из нагрузки для каждого тома отдельно – грубо говоря для логов рэйд10 (или зеркало при низкой нагрузке), для файлопомоек рэйд5 (или 6 в особо важных случаях), для файлов БД рэйд5 или 10 исходя из соотношения чтение-запись.


Схема подключения серверов.
Тут на самом деле много нюансов.
Если серверов 1-2, то их можно подключить напрямую, без свича. Правда некоторые системы в этом случае однозначно требуют двухпортовое подключение каждого хоста для работы дублирования контроллеров. Хотя дублирование каналов крайне желательно в любом случае – если хост-адаптеры достаточно надежны, то вот свич может вылететь – и что Вы тогда будете делать? В общем так – адаптер в каждом сервере может быть и один, но вот свичей (если они есть) должно быть как минимум два (в крайнем случае провода вручную перекинуть можно – дело минутное). Для дублирования каналов требуется дополнительный софт – иногда он есть в комплекте бесплатно, иногда за деньги. Можно также воспользоваться сторонними средствами типа Веритаса.
Сложные случаи с многосвичевыми фабриками рассматривать не буду – отдельная песня.
Еще один глупый момент, который всплывает достаточно часто – большинство файловых систем не позволяют работать одновременно нескольким серверам с одним томом (хотя на аппаратном уровне это вполне возможно – если не настроено распределение прав доступа на массиве - LUN Mapping). Поэтому каждому серверу в большинстве случаев нужен собственный LUN. Если по какой-то причине нужен одновременный доступ, смотрите на специальные средства типа Sanbolic MelioFS, IBM GPFS и SAN FS, RedHat GFS и т.п.
Если же настраиваете лун маппинг, то часто возникают моменты, связанные с тем, что сервер видит луны не 0-1-2-3…, а 2-7-15… (т.е. часть лунов, принадлежащих другим серверам, он не видит вообще и начинает дурить – это зависит от операционки). Для этого в серьезных системах есть отдельные средства – типа Storage Partitioning, когда дисковая система делится на несколько виртуальных, с правильным порядком нумерации лунов. Если это Вам важно, обратите внимание на наличие соответствующего функционала заранее.


Объем.
Ну тут все просто - надо определить сколько гигабайт надо под каждую из задач-серверов. Имейте в виду, что реальное количество дисков будет существенно больше - большие потери будут на парити (особенно рэйд10) и запасные диски (standby, hot spare - не путать с hot swap). Дополнительные потери связаны с распределением дисков по группам (ввиду дискретности). Стэндбайных дисков условно надо одну штуку на полку, но если в системе используются разные винты, то придется использовать выделенную запаску на каждый массив (dedicated spare).


Масштабируемость.
Вы собираетесь купить достаточно дорогую вещь и совсем не в Ваших интересах заплатить сейчас поменьше, а через год выкинуть ее на свалку истории. Поэтому необходимо пообщаться с руководством и выяснить, нет ли у них планов грандиозного развития. Ну как минимум прикинуть годовой-месячный рост нагрузки и экстраполировать с запасом на разумный срок (раза этак в два – в этом деле переборщить трудно, обычно все ошибаются в меньшую сторону. А системы такого класса живут обычно долго – три-пять лет, а то и больше). От этого будет зависеть класс системы – важно, чтобы через годы она потянула увеличившееся число шпинделей. Если у Вас сейчас не хватает денег, чтобы заложиться на мощную систему, подумайте – сможете ли Вы потом разумно пристроить младшую модель (например под резерв или более слабые задачи). Если нет – лучше ищите деньги.


Отказоустойчивость и сервис.
Первое, что надо иметь в виду – ломается ВСЕ. А отказ дисковой системы намного страшнее отказа сервера – если сервер легко заменить на какую-нибудь времянку, то если упала дисковая система, Вы имеете ПРОБЛЕМУ.
Поэтому перед покупкой стоит убедиться в наличии в пределах досягаемости сервис-центра производителя. Если речь идет о небольшом городе, то заранее оговорите сервисные условия – едва ли Вам заменят железо на следующий день. Да и вообще попросите разъяснить тонкости гарантийной политики – даже бренды первого класса вовсе не обеспечивают моментальную замену забесплатно. Время реакции next business day вовсе не означает, что на следующий день Вам все починят – только приедут посмотреть. Может быть починят, может быть нет – как повезет. Скорее всего для починки на следующий день придется заключать дополнительный сервисный контракт.
Кроме того – починят-то починят. Но что Вы будете делать сутки? И ведь никто не гарантирует, что Вам спасут данные – формально обязаны только железку отремонтировать. А вчерашний бэкап в ряде случаев неприемлем (и уж почти всегда крайне неприятен).
Поэтому спасение утопающих… Если суточный, а то и больше, простой неприемлем, стоит задуматься насчет организации резервной системы. Пусть она будет слабая – по крайней мере сможете как-то работать.
Особо стоит отметить, что значительная часть систем по нашему опыту вылетала не самостоятельно, а по причине внешнего воздействия (отказ кондиционера, электрика, hands.dll). Если хотите защититься и от этого (кроме рук), см. следующий пункт.


Функционал.
В системах начального уровня (Infortrend, Xyratex, HP MSA…) надеяться на что-то умное не стоит. Но вот системы среднего класса имеют кучу полезных вещей. Все перечислять не буду, но на среднем уровне наиболее востребованы зеркалирование томов и дисковых систем целиком и снапшоты. Если Вы решили покупать серьезную систему – грех не воспользоваться функциями, которые она предоставляет. Со снапшотами понятно – это сильно упрощает бэкап и дает возможность гонять аналитику по свежеснятой копии БД. Зеркалирование полезно для защиты от вылета тома или системы целиком – особенно если зеркальные систему разнесены по площадкам. Конечно все стоит денег – и лицензии недешевы и функционал растет по мере роста класса системы. Поэтому иногда приходится покупать систему ненужной производительности ради какой-то фичи. Подумайте – иногда того же эффекта можно достичь использованием упомянутого выше Веритаса. Простор для размышлений тут огромный – я только хочу посоветовать помозговать над этим вопросом.
Кроме того, системы серьезного класса предоставляют ряд возможностей по тонкому тюнингу под конкретную задачу (кэш-партишенинг, префетчи всякие и т.п.). Эти вещи конечно на совести интегратора, который все это будет настраивать, но стоит иметь в виду, что системы начального уровня работают как работают, а более серьезный аппарат можно затюнить достаточно серьезно.


З.Ы. Сей опус не претендует на истину в последней инстанции – это просто перечисление наиболее частых моментов, которые нам приходится растолковывать клиентам.

З.З.Ы. Спецы, очень буду рад видеть Вашу здравую критику-дополнения. Только сразу предупреждаю – все сказанное может быть использовано для написания статьи на нашем сайте (с регардами конечно) :).

Вернуться в «Массивы - FAQ»

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 8 гостей