Как правильно выбрать схд


как выбирать?! / Parallels corporate blog / Habr

Проект любой сложности, как ни крути, сталкивается с задачей хранения данных. Таким хранилищем могут быть разные системы: Block storage, File storage, Object storage и Key-value storage. В любом вменяемом проекте перед покупкой того или иного storage-решения проводятся тесты для проверки определённых параметров в определённых условиях. Вспомнив, сколько хороших, сделанных правильно растущими руками проектов прокололись на том, что забыли про масштабируемость, мы решили разобраться:
  • Какие характеристики Block storage и File storage нужно учитывать, если хотите, чтобы при росте проекта система хранения выросла вслед за ним
  • Почему отказоустойчивость на software уровне надежнее и дешевле, чем на hardware уровне
  • Как правильно проводить тестирование, чтобы сравнивать «яблоки с яблоками»
  • Как получить на порядок больше/меньше IOPS, поменяв всего один параметр

В процессе тестирования мы применяли RAID–системы и распределенную систему хранения данных Parallels Cloud Storage (PStorage). PStorage входит в продукт Parallels Cloud Server.

Начнем с того, что определим основные характеристики, на которые нужно обратить внимание при выборе системы хранения. Они же будут определять структуру поста.

  1. Отказоустойчивость
  2. Скорость восстановления данных
  3. Производительность, соответствующая вашим запросам.
  4. Консистентность данных

Отказоустойчивость


Самая важное свойство системы хранения данных – это то, что система призвана СОХРАНЯТЬ данные без каких-либо компромиссов, то есть обеспечивать максимальную доступность и ни в коем случае не потерять даже малой их части. Почему-то очень многие задумываются о производительности, цене, но мало внимания уделяют надежности хранения данных.

Для обеспечения отказоустойчивости в случае сбоя существует одна-единственная техника – резервирование. Вопрос в том, на каком уровне применяется резервирование. С некоторым грубым упрощением, можно сказать, что уровня два: Hardware и Software.

Резервирование на уровне Hardware давно зарекомендовало себя в Enterprise-системах. SAN/NAS коробки имеют двойное резервирование всех модулей (два, а то и три блока питания, пара плат «мозгов») и сохраняют данные одновременно на нескольких дисках внутри одной коробки. Лично я метафорически представляю это себе как очень безопасную кружку: максимально надежную для сохранения жидкости внутри, с толстыми стенками и обязательно с двумя ручками на случай, если одна из них сломается.

Резервирование на уровне Software только начинает проникать в Enterprise-системы, но с каждым годом отъедает все больший и больший кусок у HW решений. Принцип тут прост. Такие системы не полагаются на надежность железа. Они считают, что оно априори ненадежно, и решают задачи резервирования на уровне ПО, создавая копии (реплики) данных и храня их на физически разном железе. Продолжая аналогию с чашками, это — когда есть несколько совершенно обычных чашек, и ты разлил чай в обе, вдруг одна разобьется.

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

Расскажу, как решается вопрос резервирования на примере Parallels Cloud Storage (PStorage). PStorage не имеет привязки к какому-либо вендору железа и способен работать на совершенно обычных машинах, вплоть до настольных PC. Мы не доверяем железу, поэтому архитектура PStorage рассчитана на потерю любого физического сервера целиком (а не только отдельного диска). Все данные в Parallels Cloud Storage хранятся в нескольких копиях (репликах). При этом PStorage никогда не хранит более одной копии на физическом сервере/стойке/комнате (как захотите). Мы рекомендуем хранить 3 копии данных, чтобы быть защищенным от одновременного сбоя сразу двух серверов/стоек.


Комментарий: на рисунке показан пример кластера, хранящего данные в двух копиях.

Скорость восстановления данных


Что происходит, если один из дисков выходит из строя?

Для начала рассмотрим обычный HW RAID1 (mirror) из двух дисков. В случае выпадения одного диска, RAID продолжает работать с оставшимся, ожидая момента замены сломавшегося диска. Т.е. в это время RAID уязвим: оставшийся диск хранит единственную копию данных. У одного из наших клиентов был случай, когда в их дата-центре проводили ремонт и пилили металл. Стружки летели прямо на работающие сервера, и в течение нескольких часов диски в них стали вылетать один за другим. Тогда система была организована на обычных RAID, и в результате провайдер потерял часть данных.

Сколько времени система находится в уязвимом состоянии — зависит от времени восстановления. Эту зависимость описывает следующая формула:

MTTDL ~= 1 / T^2 * С, где T – это время восстановления, а the mean time to data loss (MTTDL) — среднее время наработки до потери данных, С — некий коэффициент.
Итак, чем быстрее система восстановит необходимое количество копий данных, тем меньше вероятность потерять данные. Здесь мы даже опустим тот факт, что для начала процесса восстановления HW RAID администратору нужно заменить дохлый диск на новый, а на это тоже нужно время, особенно если диск нужно заказывать.

Для RAID1 время восстановления – это время, за которое RAID контроллер перельет данные с рабочего диска на новый. Как легко догадаться, скорость копирования будет равна скорости чтения/записи HDD, то есть примерно 100 MB/s, если RAID контроллер совершенно не нагружен. А если в это время RAID котроллер грузят извне, то скорость будет в несколько раз ниже. Вдумчивый читатель проведет аналогичные расчёты для RAID10, RAID5, RAID6 и придет к выводу, что любой HW RAID восстанавливается со скоростью не выше скорости одного диска.

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

На Software уровне гораздо больше возможностей для оптимизации. Например, в PStorage данные распределяются по всему кластеру и по всем дискам кластера, и в случае выхода из строя одного из дисков репликация начинается автоматически. Здесь не нужно ждать, когда администратор заменит диск. Кроме того, в репликации участвуют все диски кластера, поэтому скорость восстановления данных намного выше. Мы записывали данные в кластер, отключали один сервер из кластера и замеряли время, за которое кластер восстановит недостающее количество реплик. На графике результат для кластера из 7/14/21 физической ноды с двумя SATA дисками по 1TB. Кластер собран на 1GB сети.

Если использовать 10Gbit сеть, то скорость будет еще выше.

Комментарий: Здесь нет ошибки в том, что на 1Gbit сети скорость восстановления кластера из 21 сервера — почти гигабайт в секунду. Дело в том, что данные, сохранённые в Parallels Cloud Storage, распределены по дискам кластера (некий stripe в масштабе кластера), таким образом, мы получаем возможность параллельно производить копирование данных с разных дисков на разные. То есть нет единой точки владения данными, которая могла бы быть узким местом теста.

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

Как правильно тестировать производительность — советы


Основываясь на нашем опыте тестирования систем хранения данных, я бы выделил основные правила:
  1. Надо «определиться с хотелками». Что именно хочется получить от системы и сколько. Наши клиенты в большинстве случаев используют Parallels Cloud Storage для построения кластера высокой доступности для виртуальных машин и контейнеров. То есть каждая из машин кластера одновременно предоставляет и storage, и исполняет виртуальные машины. Таким образом, в кластере не требуется выделенной внешней «хранилки данных». В терминах производительности это значит, что кластер получает нагрузку от каждого сервера. Поэтому в примере мы будем всегда нагружать кластер параллельно со всех физических серверов кластера.
  2. Не нужно использование хорошо сжимаемые шаблоны данных. Многие HDDs/SSDs диски, системы хранения данных, а также виртуальные машины иногда имеют специальные Low-level оптимизации для обработки нулевых-данных. В таких ситуациях легко заметить, что запись нулей на диск происходит несколько быстрее, чем запись случайных данных. Типичным примером такой ошибки служит всем известный тест:
    dd if=/dev/zero of=/dev/sda size=1M 
    Лучше использовать случайные данные при тестировании. При этом генерация этих данных не должна влиять на сам тест. Т.е. лучше сгенерировать случайные данные заранее, например в файл. В противном случае тест упрется в генерацию данных, как в следующем примере:
    dd if=/dev/random of=/dev/sda size=1M 
  3. Учитывайте расстояние между компонентами, разнесенными друг от друга. Естественно, что коммуникация между распределёнными компонентами может содержать задержки. Стоит помнить об этом возможном узком месте при нагрузках. Особенно сетевых задержках и пропускной способности сети.
  4. Отведите не меньше минуты на проведение теста. Время теста должно быть продолжительным.
  5. Проводите один тест несколько раз, чтобы сгладить отклонения.
  6. Используйте большой объем данных для нагрузки (working set). Working set – это очень важный параметр, так как он сильно влияет на производительность. Именно он может изменить результат тестирования в десятки раз. Например, с RAID контроллером Adaptec 71605, random I/O на 512M файле показывает 100K iops, а на 2GB файле — всего 3К IOPS. Разница в производительности в 30 раз обусловлена RAID-кешем (попаданием и не попаданием в кеш в зависимости от объема нагрузки). Если вы собираетесь работать с данными больше, чем объем кэша вашей системы хранения (в данном примере 512M), то используйте именно такие объемы. Для виртуальных машин мы используем 16GB.
  7. И конечно, всегда сравнивайте только «яблоки с яблоками». Необходимо сравнивать системы с одинаковой отказоустойчивостью на одинаковом железе. Например, нельзя сравнивать RAID0 c PStorage, так как PStorage обеспечивает отказоустойчивость при вылете дисков/серверов, а RAID0 нет. Правильно в этом случае будет сравнивать RAID1/6/10 c PStorage.

Ниже приведу результаты тестирования по описанной методологии. Мы сравниваем производительность локального RAID1 («host RAID 1») с кластером PStorage («PCS»). Те самые «яблоки с яблоками». Следует обратить внимание, что необходимо сравнивать системы с одинаковым уровнем избыточности. PStorage в этих тестах хранил информацию в двух копиях (replicas=2) вместо рекомендованных трех, чтобы уровень отказоустойчивости быть одинаковый для обоих систем. Иначе сравнение было бы нечестным: PStorage (replicas=3) позволяет потерять 2 любых диска/сервера одновременно, когда RAID1 из 2 дисков — всего 1. Мы используем одинаковое железо для всех тестов: 1,10,21 одинаковых физических серверов с двумя 1TB SATA дисками, 1Gbit сетью, core i5 CPU, 16GB RAM. Если кластер состоит из 21 сервера, то его производительность сравнивается с суммарной производительностью 21 локального RAID. Нагрузка производилась в 16 потоков на каждой физической ноде одновременно. Каждая нода имела working set в 16GB, то есть, например, для RANDOM 4K теста в целом на кластере нагрузчики случайно ходили по 336GB данным. Время нагрузки — 1 минута, каждый тест проводился 3 раза.

Колонки «PCS+SSD» показывают производительность того же кластера, но с SSD-кешированием. PStorage имеет встроенную возможность использовать локальные SSD для write-журналирования, read-кеширования, что позволяет в несколько раз превзойти производительность локальных вращающихся дисков. Также SSD диски могут быть использованы для создания отдельного слоя (tier) с большей производительностью.

Выводы


Коротко резюмирую:
  1. Выбирая тип резервирования, склоняемся к «уровню ПО». Software уровень предоставляет больше возможностей для оптимизации и позволяет снизить требования к железу и удешевить систему в целом.
  2. Тесты проводим на определенных условиях (см. наши советы)
  3. Обращаем внимание на скорость восстановления – очень важный параметр, который при недостаточной эффективности может попросту погубить часть бизнеса.

Также вы можете протестировать и наше собственное решение, тем более что мы даем это сделать бесплатно. По крайней мере, на наших собственных тестах Parallels Cloud Storage показывает наибольшую скорость восстановления данных в случае потери диска (больше, чем в RAID системах, включая SAN) и производительность как минимум не хуже локального RAID, а с SSD-кешированием – и выше.

О консистентности данных мы планируем поговорить подробнее в отдельном посте.

Как попробовать Parallels Cloud Storage


Официальная страничка продукта тут. Чтобы бесплатно попробовать, заполните анкету.
Также PStorage доступен для проекта OpenVZ.
Почитать о том, как PCS работает в FastVPS можно в этом посте.
Что показывают ваши тесты, плюсы-минусы – можем подробно обсудить в комментариях.

habr.com

Как выбрать СХД, не выстрелив себе в ногу / Habr

Введение


Пришла пора покупать СХД. Какую взять, кого слушать? Вендор А рассказывает про вендора B, а еще есть интегратор C, который рассказывает обратное и советует вендора D. В такой ситуации и у опытного архитектора по системам хранения голова пойдет кругом, особенно со всеми новыми вендорами и модными сегодня SDS и гиперконвергенцией.

Итак, как же во всем этом разобраться и не оказаться в дураках? Мы (AntonVirtual Антон Жбанков и korp Евгений Елизаров) попробуем об этом рассказать русским языком по белому.
Статья во многом перекликается, и фактически является расширением “Дизайна виртуализованного ЦОД” в плане выбора систем хранения данных и обзора технологий систем хранения. Мы кратко рассмотрим общую теорию, но рекомендуем ознакомиться и с указанной статьей.

Зачем


Часто можно наблюдать ситуацию как приходит новый человек на форум или в специализированный чатик, как например Storage Discussions и задает вопрос: “вот мне предлагают два варианта СХД — ABC SuperStorage S600 и XYZ HyperOcean 666v4, что посоветуете”?

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

Так вот, ключевой и самый первый вопрос, который нужно себе задать задолго до сравнивания спецификаций в коммерческих предложениях — ЗАЧЕМ? Зачем нужна эта СХД?

Ответ будет неожиданным, и очень в стиле Тони Роббинса — чтобы хранить данные. Спасибо, капитан! И тем не менее, иногда мы так далеко углубляемся в сравнение деталей, что забываем зачем все это вообще делаем.

Так вот, задача системы хранения данных — это хранение и предоставление доступа к ДАННЫМ с заданной производительностью. С данных же мы и начнем.

Данные


Тип данных


Что за данные мы планируем хранить? Очень важный вопрос, который может вычеркнуть очень многие СХД даже из рассмотрения. Например, планируется хранение видеозаписей и фотографий. Сразу можно вычеркивать системы, рассчитанные под случайный доступ малым блоком, или системы с фирменными фишками в компрессии / дедупликации. Это могут быть просто превосходные системы, ничего плохого не хотим сказать. Но в данном случае их сильные стороны или станут напротив слабыми (видео и фото не компрессируются) или просто значительно увеличат стоимость системы.

И наоборот, если целевое использование нагруженная транзакционная СУБД, то превосходные потоковые системы под мультимедиа, способные выдавать гигабайты в секунду, будут плохим выбором.

Объем данных


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

С другой стороны, зачем городить огород, если хранить и обрабатывать надо 500 ГБ данных? Всего 500. Бытовые SSD (с низким DWPD) подобного объема стоят всего ничего. Зачем для этого строить фабрику Fiber Channel и покупать внешнюю СХД высокого класса стоимостью в чугунный мост?

Какой процент от общего объема горячие данные? Насколько неравномерна нагрузка по объему данных? Именно тут может очень помочь технология многоуровневого хранения или Flash Cache, если объем горячих данных мизерный по сравнению с общим. Либо наоборот, при равномерной нагрузке по всему объему, часто встречающейся в потоковых системах (видеонаблюдение, некоторые системы аналитики) подобные технологии не дадут ничего, и лишь увеличат стоимость / сложность системы.

ИС


Обратная сторона данных — это информационная система, использующая эти данные. ИС обладает набором требований, которые наследуют данные. Подробнее об ИС см в “Дизайне виртуализованного ЦОД”.
Требования по отказоустойчивости / доступности

Требования по отказоустойчивости / доступности данных наследуются от использующей их ИС и выражаются в трех числах — RPO, RTO, доступность.

Доступность — доля за заданный промежуток времени, в течение которого данные доступны для работы с ними. Выражается обычно в количестве 9. Например, две девятки в год означает, что доступность равна 99%, или иначе допускается 95 часов недоступности в год. Три девятки — 9,5 часов в год.

RPO / RTO — это показатели не суммарные, а на каждый инцидент (аварию), в отличие от доступности.

RPO — объем потерянных при аварии данных (в часах). Например, если происходит резервное копирование раз сутки, то RPO = 24 часа. Т.е. При аварии и полной потере СХД могут быть потеряны данные объемом до 24 часов (с момента резервной копии). Исходя из заданного для ИС RPO, например, пишется регламент резервного копирования. Также, исходя из RPO, можно понять насколько нужна синхронная / асинхронная репликация данных.

RTO — время восстановления сервиса (доступа к данным) после аварии. Исходя из заданного значения RTO мы можем понять нужен ли метрокластер, или достаточно однонаправленной репликации. Нужна ли многоконтроллерная СХД hi end класса — тоже.

Требования по производительности

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

У вас уже есть СХД и вы ищите ей замену или хотите приобрести ещё одну для расширения. Здесь всё просто. Вы понимаете, какие сервисы у вас уже есть и какие вы планируете внедрять в ближайшей перспективе. Основываясь на текущих сервисах вы имеете возможность собрать статистику по производительности. Определиться с текущим количеством IOPS и нынешних задержках — каковы эти показатели и хватает ли их для ваших задач? Сделать это можно как на самой системе хранения данных, так и со стороны хостов, которые к ней подключены.

Причём смотреть нужно не просто текущую нагрузку, а за какой то период (лучше месяц). Посмотреть каковы максимальные пики в дневное время, какую нагрузку создаёт резервное копирование и т.д. Если ваша СХД или ПО к ней не даёт вам полный набор этих данных, можно воспользоваться бесплатным RRDtool, который умеет работать с большинством наиболее популярных СХД и коммутаторов и сможет предоставить вам подробную статистику по производительности. Также стоит смотреть нагрузку и на хостах, которые работают с данной СХД, по конкретным виртуальным машинам или что конкретно у вас работает на данном хосте.

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

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

И, внимание, самый правильный вариант с точки зрения практического применения — это пилот на текущем оборудовании, либо оборудовании предоставленном для теста вендором / интегратором.

Спецтребования

Спецтребования — все то, что не подпадает под требования о производительности, отказоустойчивости и функциональности по непосредственной обработке и предоставлению данных.

Одним из самых простых спецтребований к системе хранения данных можно назвать “отчуждаемые носители информации”. И сразу становится понятно, что данная система хранения данных должна включать в себя ленточную библиотеку или просто стример, на который сбрасывается резервная копия. После чего специально обученный человек подписывает ленту и гордо несет ее в специальный сейф.
Другой пример спецтребования — защищенное противоударное исполнение.

Где


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

Заказчик


Для кого планируется данная СХД? Вопрос имеет под собой следующие основания:

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

Госзаказчик — дело иное. 44 ФЗ и прочие прелести с тендерами и ТЗ, которые могут быть оспорены.

Заказчик под санкциями
Ну тут вопрос очень простой — выбор ограничивается только доступными для данного заказчика предложениями.

Внутренние регламенты / разрешенные к закупке вендоры / модели
Вопрос тоже крайне прост, но о нем надо помнить.

Где физически


В данной части мы рассматриваем все вопросы с географией, каналами связи, и микроклиматом в помещении размещения.
Персонал

Кто будет работать с данной СХД? Это не менее важно, чем то, что СХД непосредственно умеет.
Насколько бы не была перспективна, крута и замечательна СХД от вендора А, смысла ставить ее наверное немного, если персонал умеет работать только с вендором B, и дальнейших закупок и постоянного сотрудничества с А не планируется.

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

Окружение

Ну и разумеется немаловажный вопрос — в каком окружении будет работать данная СХД.
  • Что с электропитанием / охлаждением?
  • Какое подключение
  • Куда она будет смонтирована
  • И тд.

Зачастую данные вопросы считаются сами собой разумеющимися и особо не рассматриваются, но иногда именно они могут перевернуть все с точностью до наоборот.

Что


Вендор


На сегодня (середина 2019) российский рынок СХД можно поделить на условные 5 категорий:
  1. Высший дивизион — заслуженные компании с широкой линейкой от самых простых дисковых полок до hi-end (HPE, DellEMC, Hitachi, NetApp, IBM / Lenovo)
  2. Второй дивизион — компании с ограниченной линейкой, нишевые игроки, серьезные вендоры SDS или поднимающиеся новички (Fujitsu, Datacore, Infinidat, Huawei, Pure и тд)
  3. Третий дивизион — нишевые решения в ранге low end, дешевый SDS, наколенные поделия на ceph и других открытых проектах (Infortrend, Starwind и тд)
  4. SOHO сегмент — малые и сверхмалые СХД уровня дом/малый офис (Synology, QNAP и тд)
  5. Импортозамещенные СХД — сюда входят как железо первого дивизиона с переклеенными лейблами, так и редкие представители второго (RAIDIX, дадим им авансом второй), но в основном это третий дивизион (Aerodisk, Baum, Depo и тд)

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

Один из немаловажных факторов при выборе вендора — текущая среда. Сколько и каких СХД у вас уже есть, с какими СХД умеют работать инженеры. Нужен ли вам еще один вендор, еще одна точка контакта, будете ли вы мигрировать постепенно всю нагрузку с вендора А на вендора B?

Не следует плодить сущности сверх необходимого.

iSCSI / FC / File


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

FCoE скорее мертв, чем жив.

FC vs iSCSI. Одно из ключевых преимуществ FC в 2019 перед IP СХД, выделенная фабрика под доступ к данным, нивелируется выделенной IP сетью. Глобальных преимуществ у FC перед IP сетями нет и на IP можно строить СХД любого уровня нагрузки, вплоть до систем для тяжелых СУБД для АБС крупного банка. С другой стороны, смерть FC пророчат уже не первый год, но этому постоянно что то мешает. На сегодня, например, некоторые игроки на рынке СХД активно развивают стандарт NVMEoF. Разделит ли он участь FCoE — покажет время.

Файловый доступ также не является чем то недостойным внимания. NFS / CIFS прекрасно показывают себя в продуктивных средах и при правильном проектировании имеют не больше нареканий, чем блочные протоколы.

Гибридные / All Flash Array


Классические СХД бывают 2 видов:
  1. AFA (All Flash Array) — системы, оптимизированные для использования SSD.
  2. Гибридные — позволяющие использовать как HDD, так и SSD или их сочетание.

Главное их отличие — поддерживаемых технологии эффективности хранения и максимальный уровень производительности (высокие показатели IOPS и низкие задержки). И те и другие системы (в большинстве своих моделей, не считая low-end сегмент) могут работать как блочные устройства, так и файловые. От уровня системы зависит и поддерживаемый функционал, и у младших моделей, он чаще всего урезан до минимального уровня. На это стоит обращать внимание, когда вы изучаете характеристики конкретной модели, а не просто возможности всей линейки в целом. Так же, конечно, от уровня систему зависят и её технические характеристики, такие как процессор, объём памяти, кэша, количество и типы портов и т.д. С точки зрения же По управления, AFA от гибридных (дисковых) систем отличаются лишь в вопросах реализации механизмов работы с SSD накопителями, и даже если вы используете SSD в гибридной системе, это совсем не значит, что вы сможете получить уровень производительности на уровне AFA системы. Так же в большинстве случаев inline механизмы эффективного хранения на гибридных системах отключены, а их включение ведёт к потере в производительности.

Специальные СХД


Помимо СХД общего назначения, ориентированных прежде всего на оперативную обработку данных, существуют специальные СХД с ключевыми принципами, в корне отличающимися от привычных (низкая задержка, много IOPS):

Медиа.

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

Дедуплицирующие СХД для резервных копий.

Поскольку резервные копии отличаются редкой в обычных условиях похожестью друга на друга (средняя резервная копия отличается от вчерашней на 1-2%), данный класс систем крайне эффективно упаковывает записанные на них данные в рамках достаточно небольшого количества физических носителей. Например, в отдельных случаях коэффициенты компрессии данных могут достигать 200 к 1.

Объектные СХД.

В этих СХД нет привычных томов с блочным доступом и файловых шар, а более всего они напоминают огромную базу данных. Доступ к объекту, хранящемуся в подобной системе, осуществляется по уникальному идентификатору, либо по метаданным (например все объекты формата JPEG, с датой создания между XX-XX-XXXX и YY-YY-YYYY).

Compliance системы.

Не так часто встречаются в России на сегодня, но упомянуть о них стоит. Назначение таких СХД — гарантированное хранение данных для соответствия политикам безопасности или требованиям регуляторов. В некоторых системах (например EMC Centera) была реализована функция запрета на удаление данных — как только ключ повернут и система перешла в данный режим, ни администратор, ни кто либо другой физически не могут удалить уже записанные данные.

Фирменные технологии


Flash cache

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

При этом необходимо понимать профиль нагрузки и степень локализации обращений к блокам томов хранения. Флэш кэш – технология для нагрузок с высокой локализацией запросов, и практически неприменима для равномерно нагруженных томов (как например для систем аналитики).

На рынке доступны две реализации флэш кэша:

  • Read Only. В этом случае кэшируются только данные на чтение, а запись проходит сразу на диски. Некоторые производители, как например, NetApp, считают что запись на их СХД проходит и так оптимальным образом, и кэш никак не поможет.
  • Read/Write. Кэшируется не только чтение, но и запись, что позволяет буферизовать поток и снизить влияние RAID Penalty, а как следствие повысить общую производительность для СХД с не таким оптимальным механизмом записи.

Tiering

Многоуровневое хранение (тиринг) — технология объединения в единый дисковый пул уровней с разной производительностью, как например SSD и HDD. В случае ярко выраженной неравномерности обращений к блокам данных система сможет автоматически отбалансировать блоки данных, переместив нагруженные на высокопроизводительный уровень, а холодные, наоборот, на более медленный.

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

Snapshot

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

Снапшот — это снимок тома на какой то момент времени. При работе большинства систем, таких как виртуализация, БД и тд. нам необходимо снять такой снимок, из которого мы будем копировать данные в резервную копию, при этом наши ИС смогут спокойно продолжать работать с этим томом. Но стоит помнить — не все снапшоты одинаково полезны. У разных вендоров, разные подходы к созданию снапшотов, связанные с их архитектурой.

CoW (Copy-On-Write). При попытке записи блока данных его оригинальное содержимое копируется в специальную область, после чего запись проходит нормально. Таким образом предотвращается повреждение данных внутри снапшота. Естественно все эти «паразитные» манипуляции с данными вызывают дополнительную нагрузку на СХД и по этой причине вендоры с подобной реализацией не рекомендуют использовать более десятка снапшотов, а на высоконагруженных томах не использовать их вообще.

RoW (Redirect-on-Write). В данном случае, оригинальноый том натурально замораживается, а при попытке записи блока данных СХД пишет данные в специальную область в свободном пространстве, изменяя местоположение данного блока в таблице метаданных. Это позволяет уменьшить количество операций перезаписи, что в итоге нивелирует падение производительности и снимает ограничения на снапшоты и их количество.

Снапшоты бывают также двух типов по отношению к приложениям:

Application consitent. В момент создания снапшота СХД дергает агента в операционной системе потребителя, который принудительно сбрасывает дисковые кэши из памяти на диск и заставляет сделать это приложение. В этом случае при восстановлении из снапшота данные будут консистентны.

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

Зачем нужны снапшоты на системах хранения данных?

  • Безагентное резервное копирование напрямую с СХД
  • Создание тестовых сред на основе реальных данных
  • В случае с файловыми СХД может использоваться для создания сред VDI через использование снапшотов СХД вместо гипервизора
  • Обеспечение низких RPO путем создания снапшотов по расписанию с частотой значительно выше частоты резервного копирования

Cloning

Клонирование тома — работает по аналогичному принципу, что и снапшоты, но служит не просто для чтения данных, а для полноценной работы с ними. Мы имеем возможность получить точную копию нашего тома, со всем данными на нём, не делая физической копии, что позволит сэкономить место. Обычно клонирование томов используется или в Test&Dev или если вы хотите проверить работоспособность каких то обновлений на вашей ИС. Клонирование позволит сделать это максимально быстро и экономично с точки зрения дисковых ресурсов, т.к. записаны будут только изменённые блоки данных.
Репликация / журналирование

Репликация — механизм создания копии данных на другой физической СХД. Обычно существует фирменная технология у каждого вендора, работающая только внутри собственной линейки. Но также есть и сторонние решения, в том числе работающие на уровне гипервизора, как например VMware vSphere Replication.

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

Репликация делится на два подвида:

Синхронная. В случае синхронной репликации операция записи пересылается на вторую СХД немедленно и не подтверждается исполнение до тех пор, пока удаленная СХД не подтвердит. За счет этого растет задержка доступа, но зато мы имеем точную зеркальную копию данных. Т.е. RPO = 0 для случая потери основной СХД.

Асинхронная. Операции записи исполняются только на главной СХД и подтверждаются немедленно, параллельно накапливаясь в буфере для пакетной передачи на удаленную СХД. Подобный вид репликации актуален для менее ценных данных, либо для каналов низкой пропускной способности либо имеющих высокую задержку (характерно для расстояний свыше 100 км). Соответственно RPO = частоте пакетной отправки.

Зачастую вместе с репликацией существует механизм журналирования дисковых операций. В этом случае выделяется специальная область для журналирования и хранятся операции записи определенной глубины по времени, либо ограниченные объемом журнала. Для отдельных фирменных технологий, как например EMC RecoverPoint, существует интеграция с системным ПО, позволяющим привязать определенные закладки на конкретную запись в журнале. Благодаря этому возможно откатить состояние тома (либо создать клон) не просто на 23 апреля 11 часов 59 секунд 13 миллисекунд, а на момент, предшествовавший “DROP ALL TABLES; COMMIT”.

Metro cluster

Метро кластер — технология, позволяющая создать двунаправленную синхронную репликацию между двумя СХД таким образом, что со стороны эта пара выглядит как одна СХД. Применяется для создания кластеров с географически разнесенными плечами на метро- расстояниях (менее 100 км).

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

  • Полная автоматизация процесса восстановления после смерти одного из датацентров. Без каких либо дополнительных средств все ВМ, работавшие в умершем датацентре, будут автоматически перезапущены в оставшемся. RTO = таймаут кластера высокой доступности (15 секунд для VMware) + время загрузки операционной системы и старта сервисов.
  • Disaster avoidance или, по-русски, избежание катастроф. Если запланированы работы по электропитанию в датацентре 1, то мы заранее, до начала работ, имеем возможность мигрировать всю важную нагрузку в датацентр 2 нон стоп.

Виртуализация

Виртуализация СХД — это технически использование томов с другой СХД в качестве дисков. СХД-виртуализатор может просто прокинуть чужой том до потребителя как свой, попутно зеркалировав его на еще одну СХД, или даже создать RAID из внешних томов.
Классические представители в классе виртуализации СХД — это EMC VPLEX и IBM SVC. Ну и разумеется СХД с функцией виртуализации — NetApp, Hitachi, IBM / Lenovo Storwize.

Зачем может понадобиться?

  • Резервирование на уровне СХД. Создается зеркало между томами, причем одна половина может быть на HP 3Par, а другая на NetApp. А виртуализатор от EMC.
  • Переезд данных с минимальным простоем между СХД разных производителей. Предположим, что данные надо мигрировать со старого 3Par, который пойдет под списание, на новый Dell. В этом случае потребители отключаются от 3Par, тома прокидываются под VPLEX и уже презентуются потребителям заново. Поскольку ни бита на томе не изменилось, работа продолжается. Фоном запускается процесс зеркалирования тома на новый Dell, а по завершению зеркало разбивается и 3Par отключается.
  • Организация метрокластеров.

Компрессия / дедупликация

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

Компрессия и дедупликация бывают 2 видов:

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

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

Стоит сказать, что большинство вендоров используют оба вида, что позволяет оптимизировать эти процессы и тем самым повысить их эффективность. У большинства вендоров СХД, есть в наличии утилиты, которые позволяют проанализировать ваши наборы данных. Данные утилиты, работают по той же логике, что реализована и в СХД, по этому оценочный уровень эффективности будет совпадать. Также не стоит забывать, что у многих вендоров есть программы гарантии эффективности, которые обещают уровень не ниже заявленного для определённого (или всех) типов данных. И не стоит пренебрегать данной программой, ведь рассчитывая систему под свои задачи, с учётом коэффициента эффективности конкретной системы, вы можете сэкономить на объёме. Так же стоит учитывать, что эти программы рассчитаны на AFA системы, но благодаря закупке меньшего объёма SSD, нежели HDD в классических системах, это позволит снизить их стоимость, и если не сравняться со стоимостью дисковой системы, то довольно сильно к ней приблизиться.

Модель


И вот здесь мы приходим к правильно заданному вопросу.

“Вот мне предлагают два варианта СХД — ABC SuperStorage S600 и XYZ HyperOcean 666v4, что посоветуете”

Превращается в “Вот мне предлагают два варианта СХД — ABC SuperStorage S600 и XYZ HyperOcean 666v4, что посоветуете?

Целевая нагрузка смешанные виртуальные машины VMware с контуров продуктив / тест / разработка. Тест = продуктиву. 150 ТБ на каждый с пиковой производительностью 80 000 IOPS 8kb блоком 50% случайного доступа 80/20 чтение-запись. 300 ТБ на разработку, там 50 000 IOPS хватит, 80 случайный, 80 запись.

Продуктив предположительно в метрокластер RPO = 15 минут RTO = 1 час, разработку в асинхронную репликацию RPO = 3 часа, тест на одной площадке.

Будет 50ТБ СУБД, было бы неплохо для них журналирование.

У нас везде серверы Dell, СХД старые Hitachi, еле справляются, планируем рост 50% нагрузки по объему и производительности”

Как говорится, в правильно сформулированном вопросе содержится 80% ответа.

Дополнительная информация


С чем стоит ознакомиться дополнительно по мнению авторов

Книги


  • Олифер и Олифер “Компьютерные сети”. Книга поможет систематизировать и возможно лучше понимать как работает среда передачи данных для IP / Ethernet систем хранения
  • “EMC Information Storage and Management”. Прекрасная книга по основам СХД, почему, как и зачем.

Форумы и чаты


Общие рекомендации


Цены

Теперь что же касается цен — вообще на СХД цены если и попадаются, то обычно это List price, от которой каждый заказчик получает индивидуальную скидку. Размер скидки складывается из большого числа параметров, так что предсказать, какую конечную цену получит именно ваша компания, без запроса к дистрибьютору просто невозможно. Но при этом, в последнее время low-end модели стали появляться в обычных компьютерных магазинах, таких как, например nix.ru или xcom-shop.ru. В них можно сразу приобрести интересующую вас систему по фиксированный цене, как любые компьютерные комплектующие.

Но хочется отметить сразу, что прямое сравнение по TB/$ не является верным. Если подходить с этой точки зрения, то наиболее дешёвым решением будет простой JBOD + сервер, что не даст ни той гибкости, ни той надёжности, которые обеспечивает полноценная, двухконтроллерная СХД. Это совершенно не значит, что JBOD гадость гадостная и пакость пакостная, просто нужно опять-таки очень чётко понимать — как и для каких целей вы будете использовать это решение. Часто можно услышать, что в JBOD нечему ломаться, там же один бэкплейн. Однако и бэкплейны бывает выходят из строя. Все ломается рано или поздно.

Итого

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

Покупайте HDD только если вы уверены, что вам нужны HDD. Для низких нагрузок и несжимаемых типов данных, в ином случае, стоит обратить на программы гарантии эффективности хранения на SSD, которые сейчас есть у большинства вендоров (и они действительно работают, даже в России), но тут всё зависит от приложений и данных, которые будут располагаться на данной СХД.

Не гонитесь за дешевизной. Порой под эти скрывается множество неприятных моментов, один из которых Евгений Елизаров описывал в своих статьях про Infortrend. И что, в конечном итоге, эта дешевизна может выйти вам же боком. Не стоит забыть — «скупой платит дважды».

habr.com

О сетях хранения данных / Habr

Решил написать небольшую статейку о сетях хранения данных (СХД), тема эта достаточно интересная, но на Хабре почему-то не раскрыта. Постараюсь поделиться личным опытом по построению и поддержке SAN.

Что это?
Сеть хранения данных, или Storage Area Network — это система, состоящая из собственно устройств хранения данных — дисковых, или RAID — массивов, ленточных библиотек и прочего, среды передачи данных и подключенных к ней серверов. Обычно используется достаточно крупными компаниями, имеющими развитую IT инфраструктуру, для надежного хранения данных и скоростного доступа к ним.
Упрощенно, СХД — это система, позволяющая раздавать серверам надежные быстрые диски изменяемой емкости с разных устройств хранения данных.

Немного теории.
Сервер к хранилищу данных можно подключить несколькими способами.
Первый и самый простой — DAS, Direct Attached Storage (прямое подключение), без затей ставим диски в сервер, или массив в адаптер сервера — и получаем много гигабайт дискового пространства со сравнительно быстрым доступом, и при использовании RAID-массива — достаточную надежность, хотя копья на тему надежности ломают уже давно.
Однако такое использование дискового пространства не оптимально — на одном сервере место кончается, на другом его еще много. Решение этой проблемы — NAS, Network Attached Storage (хранилище, подключенное по сети). Однако при всех преимуществах этого решения — гибкости и централизованного управления — есть один существенный недостаток — скорость доступа, еще не во всех организациях внедрена сеть 10 гигабит. И мы подходим к сети хранения данных.

Главное отличие SAN от NAS (помимо порядка букв в аббревиатурах) — это то, каким образом видятся подключаемые ресурсы на сервере. Если в NAS ресурсы подключаются протоколам NFS или SMB, в SAN мы получаем подключение к диску, с которым можем работать на уровне операций блочного ввода-вывода, что гораздо быстрее сетевого подключения (плюс контроллер массива с большим кэшем добавляет скорости на многих операциях).

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

* снимаем ограничения на дальность подключения SCSI-устройств, которые обычно ограничены проводом в 12 метров,
* уменьшаем время резервного копирования,
* можем грузиться с SAN,
* в случае отказа от NAS разгружаем сеть,
* получаем большую скорость ввода-вывода за счет оптимизации на стороне системы хранения,
* получаем возможность подключать несколько серверов к одному ресурсу, то нам дает следующих двух зайцев:
o на полную используем возможности VMWare — например VMotion (миграцию виртуальной машины между физическими) и иже с ними,
o можем строить отказоустойчивые кластеры и организовывать территориально распределенные сети.

Что это дает?
Помимо освоения бюджета оптимизации системы хранения данных, мы получаем, вдобавок к тому что я написал выше:

* увеличение производительности, балансировку нагрузки и высокую доступность систем хранения за счет нескольких путей доступа к массивам;
* экономию на дисках за счет оптимизации расположения информации;
* ускоренное восстановление после сбоев — можно создать временные ресурсы, развернуть на них backup и подключить к ним сервера, а самим без спешки восстанавливать информацию, или перекинуть ресурсы на другие сервера и спокойно разбираться с умершим железом;
* уменьшение время резервного копирования — благодаря высокой скорости передачи можно бэкапиться на ленточную библиотеку быстрее, или вообще сделать snapshot (мгновенный снимок) с файловой системы и спокойно архивировать его;
* дисковое место по требованию — когда нам нужно — всегда можно добавить пару полок в систему хранения данных.
* уменьшаем стоимость хранения мегабайта информации — естественно, есть определенный порог, с которого эти системы рентабельны.
* надежное место для хранения mission critical и business critical данных (без которых организация не может существовать и нормально работать).
* отдельно хочу упомянуть VMWare — полностью все фишки вроде миграции виртуальных машин с сервера на сервер и прочих вкусностей доступны только на SAN.

Из чего это состоит?
Как я писал выше — СХД состоит из устройств хранения, среды передачи и подключенных серверов. Рассмотрим по порядку:

Системы хранения данных обычно состоят из жестких дисков и контроллеров, в уважающей себя системе как правило всего по 2 — по 2 контроллера, по 2 пути к каждому диску, по 2 интерфейса, по 2 блока питания, по 2 администратора. Из наиболее уважаемых производителей систем следует упомянуть HP, IBM, EMC и Hitachi. Тут процитирую одного представителя EMC на семинаре — «Компания HP делает отличные принтеры. Вот пусть она их и делает!» Подозреваю, что в HP тоже очень любят EMC. Конкуренция между производителями нешуточная, впрочем, как и везде. Последствия конкуренции — иногда вменяемые цены за мегабайт системы хранения и проблемы с совместимостью и поддержкой стандартов конкурентов, особенно у старого оборудования.

Среда передачи данных. Обычно SAN строят на оптике, это дает на текущий момент скорость в 4, местами в 8 гигабит на канал. При построении раньше использовались специализированные хабы, сейчас больше свитчи, в основном от Qlogic, Brocade, McData и Cisco (последние два на площадках не видел ни разу). Кабели используются традиционные для оптических сетей — одномодовые и многомодовые, одномодовые более дальнобойные.
Внутри используется FCP — Fibre Channel Protocol, транспортный протокол. Как правило внутри него бегает классический SCSI, а FCP обеспечивает адресацию и доставку. Есть вариант с подключением по обычной сети и iSCSI, но он обычно использует (и сильно грузит) локальную, а не выделенную под передачу данных сеть, и требует адаптеров с поддержкой iSCSI, ну и скорость помедленнее, чем по оптике.

Есть еще умное слово топология, которое встречается во всех учебниках по SAN. Топологий несколько, простейший вариант — точка-точка (point to point), соединяем между собой 2 системы. Это не DAS, а сферический конь в вакууме простейший вариант SAN. Дальше идет управляемая петля (FC-AL), она работает по принципу «передай дальше» — передатчик каждого устройства соединен с приемником последующего, устройства замкнуты в кольцо. Длинные цепочки имеют свойство долго инициализироваться.

Ну и заключительный вариант — коммутируемая структура (Fabric), она создается с помощью свитчей. Структура подключений строится в зависимости от количества подключаемых портов, как и при построении локальной сети. Основной принцип построения — все пути и связи дублируются. Это значит, что до каждого устройства в сети есть минимум 2 разных пути. Здесь тоже употребимо слово топология, в смысле организации схемы подключений устройств и соединения свитчей. При этом как правило свитчи настраиваются так, что сервера не видят ничего, кроме предназначенных им ресурсов. Это достигается за счет создания виртуальных сетей и называется зонированием, ближайшая аналогия — VLAN. Каждому устройству в сети присваивается аналог MAC-адреса в сети Ethernet, он называется WWN — World Wide Name. Он присваивается каждому интерфейсу и каждому ресурсу (LUN) систем хранения данных. Массивы и свитчи умеют разграничивать доступ по WWN для серверов.

Сервера подключают к СХД через HBA - Host Bus Adapter-ы. По аналогии с сетевыми картами существуют одно-, двух-, четырехпортовые адаптеры. Лучшие собаководы рекомендуют ставить по 2 адаптера на сервер, это позволяет как осуществлять балансировку нагрузки, так и обеспечивает надежность.

А дальше на системах хранения нарезаются ресурсы, они же диски (LUN) для каждого сервера и оставляется место в запас, все включается, установщики системы прописывают топологию, ловят глюки в настройке свитчей и доступа, все запускается и все живут долго и счастливо*.
Я специально не касаюсь разных типов портов в оптической сети, кому надо — тот и так знает или прочитает, кому не надо — только голову забивать. Но как обычно, при неверно установленном типе порта ничего работать не будет.

Из опыта.
Обычно при создании SAN заказывают массивы с несколькими типами дисков: FC для скоростных приложений, и SATA или SAS для не очень быстрых. Таким образом получаются 2 дисковые группы с различной стоимостью мегабайта — дорогая и быстрая, и медленная и печальная дешевая. На быструю вешаются обычно все базы данных и прочие приложения с активным и быстрым вводом-выводом, на медленную — файловые ресурсы и все остальное.

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

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

Часто при создании СХД фирмы не заказывают поддержку системы производителем. Обычно это оправдано, если у фирмы есть штат грамотных компетентных админов (которые уже 100 раз назвали меня чайником) и изрядный капитал, позволяющий закупить запасные комплектующие в потребных количествах. Однако компетентных админов обычно переманивают интеграторы (сам видел), а денег на закупку не выделяют, и после сбоев начинается цирк с криками «Всех уволю!» вместо звонка в саппорт и приезда инженера с запасной деталью.

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

Про VMWare. Насколько я знаю (спецы по виртуализации поправьте меня), только у VMWare и Hyper-V есть функционал, позволяющий «на лету» перекидывать виртуальные машины между физическими серверами. И для его реализации требуется, чтобы все сервера, между которыми перемещается виртуальная машина, были подсоединены к одному диску.

Про кластеры. Аналогично случаю с VMWare, известные мне системы построения отказоустойчивых кластеров (Sun Cluster, Veritas Cluster Server) — требуют подключенного ко всем системам хранилища.

Пока писал статью — у меня спросили — в какие RAIDы обычно объединяют диски?
В моей практике обычно делали или по RAID 1+0 на каждую дисковую полку с FC дисками, оставляя 1 запасной диск (Hot Spare) и нарезали из этого куска LUN-ы под задачи, или делали RAID5 из медленных дисков, опять же оставляя 1 диск на замену. Но тут вопрос сложный, и обычно способ организации дисков в массиве выбирается под каждую ситуацию и обосновывается. Та же EMC например идет еще дальше, и у них есть дополнительная настройка массива под приложения, работающие с ним (например под OLTP, OLAP). С остальными вендорами я так глубоко не копал, но догадываюсь, что тонкая настройка есть у каждого.

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

habr.com

Системы хранения данных (СХД) - как выбрать, системы хранения данных DAS, NAS, SAN

Отправить вопрос по решению По будням отвечаем
в течение часа

Андрей Оловянников, [email protected]

Давайте договоримся….

Целью этой статьи является не подробное изучение  различных систем хранения данных (СХД). Мы не будем анализировать всевозможные  интерфейсы – программные и аппаратные – которые используются при создании разных способов хранения данных. Не будем рассматривать «узкие места» тех или иных разновидностей организации СХД. Здесь вы не увидите подробного рассмотрения протоколов iSCSI и их реализации в виде FC (Fibre Channel ), SCSI и т.д.

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

Итак…

СХД или… СХД?

Начнем, как говорится,  с начала.

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

Системы хранения DAS

Наиболее типичный и понятный способ исполнения  СХД это DAS – Direct Attached Storages – накопители, подключающиеся напрямую к компьтеру, который управляет работой этих накопителей.

Самый простой пример DAS – обычный компьютер с установленным в нем жестким диском или DVD (CD) приводом с данными. Пример посложнее (см. рис ) – внешнее устройство-накопитель (внешний жесткий диск, дисковая полка, ленточный накопитель и т.д.), которые общаются с компьютером напрямую посредством того или иного протокола и интерфейса (SCSI, eSATA, FC и т.д.). Мы предлагаем в качестве устройств СХД DAS дисковые полки или Сервера Хранения Данных (еще одна аббревиатура СХД).

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

Нужно отметить, что при таком воплощении СХД данные напрямую видит только компьютер с DAS, все остальные пользователи имеют доступ к данным только “с разрешения” этого компьютера.

Базовые конфигурации СХД DAS вы можете посмотреть в  Каталоге СХД  

Системы хранения NAS

Еще одна достаточно простая реализация СХД – NAS (Network Attached Storage) – Сетевое Хранилище Данных (опять та же аббревиатура СХД).

Как становится понятно, доступ к данным осуществляется посредством сетевых протоколов, как правило, через привычную нам компьютерную локальную сеть (хотя сейчас уже получили распространение и боле сложные доступы к данным, хранящимся на сетевых ресурсах). Самый понятный и простой пример СХД NAS – бытовое хранилище музыки и фильмов, к которому имеют доступ сразу несколько пользователей  домашней сети.

NAS хранит данные в виде  файловой системы и, соответственно, предоставляет доступ к ресурсам посредством сетевых файловых протоколов (NFS, SMB, AFP…).

Простой пример реализации СХД NAS см. на рис. 2.

Рис. 2

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

Системы хранения SAN

Storage Area Network – один из способов реализации СХД как Системы Хранения Данных – см. выше.

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

Рис. 3

С развитием технологий хранения данных различие между системами SAN и NAS стало весьма условным. Условно их можно различить по способу хранения данных:  SAN – блочные устройства, NAS – файловая система данных.

Протоколы реализации систем SAN могут быть различные – Fibre Channel, iSCSI, AoE.

Один из архитектурных способов реализации SAN представлен на рис. 3.

Типичные примеры СХД SAN можно посмотреть в Каталоге СХД  

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

Обращайтесь!

Консультации и прием заказов:

тел. (812) 325-12-20, 8 800 700-31-24, e-mail: [email protected]

Отправить запрос

Каталог СХД Каталог серверов Конфигуратор сервера

www.ascod.ru

Разница между СХД и полкой и что такое JBOD

Давайте попробуем определить, что за устройство на картинке.
Правильно - по “морде” определить невозможно. Нужно смотреть на тыльную часть. И варианты могут быть разные:

А. Сервер

B. Система хранения данных (СХД)

C. Дисковая полка SAS-1 c двумя контроллерами JBOD (HP MSA2000sa AJ750A)

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

СХД - система хранения данных - это не полка

СХД (система хранения данных) намного сложнее полки, они дороже и имеют значительно больше нюансов.

Отличие СХД от полки это наличие “Мозга”. Контроллеры СХД это мини-серверы, со своими процессорами, памятью и операционной системой. СХД собирают из дисков RAID массивы, и передают данные по протоколам высокого уровня (iSCSI, NFS), контролируют целостность данных, позволяют создавать снапшоты и многое другое. СХД нужна если наша задача построить отказоустойчивый кластер

Однако, в случае если мы просто хотим добавить дисков в сервер, наличие “мозга” создаёт сложности: Не все СХД понимают диски объемом более 2Tb. Редкие СХД принимают от независимых производителей. Несмотря на то, что СХД полезное устройство - в этой статье мы не будем рассматривать использование СХД. Сегодня давайте разберёмся с полками.

Полка - это не СХД

Полка - достаточно простое устройство. Корпус, два блока питания, бэкплэйн и JBOD* контроллеры. Задача полки, без какой либо обработки, передать данные из накопителя в адаптер (карту RAID или HBA). Любая полка поддерживает диски любого объёма и любого производителя. Всё решает карточка в сервере. Контроллер полки - это набор микросхем с жесткой логикой.

Так выглядит подключение дисков внутри сервера

Так подключение сервер + полка.

С точки зрения схемотехники (и операционной системы), диски, установленные в полку, ничем не отличаются от дисков установленных в сервер**.
Полка имеет отдельный корпус, отдельные блоки питания, но в обоих случаях подключение производиться через RAID карточку установленную в сервер -, отличие лишь в том, что в случае с полкой, кабель подключается не по внутреннему а по внешнему разъёму.

*JBOD = Just A Bunch of Disks ( просто пачка дисков )
** Если быть совсем точным, полку можно сравнивать с сервером в котором установлен SAS экспандер - это серверы в которых количество дисков превышает 8. Для операционной системы SAS экспандер не заметен.

Вот широко распространённый RAID контроллер LSI9260-8i
8i означает 8 внутренних портов SAS/SATA

А вот его брат LSI9280-4i4e


4 внутренних и 4 внешних порта

Как называется вот этот контроллер, я думаю вы уже догадались )

Правильно - это LSI9280-8e

Все эти контроллеры собраны на одном и том же чипе LSI2108. Они обеспечивают работу по протоколам SAS/SATA со скоростью 6Gb/s и “понимают” диски объёмом более 2Tb. Попутно замечу, что на этом чипе собраны RAID контроллеры в серверах Supermicro, Intel, IBM, DELL, Fujitsu и CISCO. Многие из производителей даже не утруждают себя разработкой собственной печатной платы - меняют только прошивку. Но впрочем RAID и HBA - тема для отдельной статьи.

Вывод: если не хватает места для дисков - можно просто подключить к серверу полку. Новый сервер покупать не обязательно

Еще несколько нюансов

  1. Полки бывают не только SAS, но других типов, например FC (скорее всего они вам не нужны).

  2. Полки могут быть 3, 6 и 12Gb/s. Не все знают, что в одном кабеле mini-SAS четыре канала. Это значит, что для вычисления скорости обмена полка-контроллер показатель 3,6,12 нужно умножить на 4, а в случае если полка и контроллер соединяются двумя кабелями, на 8. Для примера 3-х гигабитная полка сможет отдавать в сервер 3x4 = 12 Гигабит! Что очень неплохо, особенно, если вы устанавливаете шпиндельные накопители. Для работы диска с сервером важна не скорость передачи данных а количество операций ввода-вывода IOPS. Об этом читайте в пункте 7.

  3. Не важно Supermicro, IBM, DELL или HP. Любая SAS полка будет работать с любым SAS контроллером. Брэнд имеет значение только когда вы подключаете полку к СХД.

  4. Полки можно собирать в гирлянду - подключая к одному контроллеру сразу несколько полок.***

    *** Если вы используете SATA диски, длина подключения не должна превышать 1М.

  5. При использовании SAS дисков (или SATA дисков с интерпозерами) можно подключать полку по двум путям, через два контроллера. Это позволяет избежать отказа в случае выхода их строя одного из контроллеров.

  6. Полки можно добавлять по мере роста количества данных, подключая их двумя путями
    “в гирлянду” вот так:

  7. SFF* полки ( обычно бывают 2U на 24-25 дисков)

    Для чего нужны SFF полки?

    Типичный сервер редко перекидывает большие блоки данных - в основном он производит хаотичные запросы чтения или записи маленьких блоков из совершенно разных мест массива. Скорость по этому показателю измеряется не в Гигабитах в секунду, а в количестве операций ввода-вывода (IOPS). И именно IOPS, а не трансфер основной параметр которому следует уделять внимание. Пользователи ПК сравнивают диски по показателям 3Gb/s, 6Gb/s, 12Gb/s, но зачастую, скорость потока диск - сервер это не Гигабиты, и даже не Мегабиты, а Килобиты! Скорости 3Gb/s, которую обеспечивают даже устаревшие интерфейсы в большинстве случаев достаточно. Сильно ошибаются те, кто думают, что улучшат производительность, сменив диски 3Gb/s на 12Gb/s. Если не изменился форм-фактор и обороты диска - скорость IOPS не измениться.

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

    LFF диски, (особенно низкооборотистые 7200RPM) не предназначены на работу в режиме случайного доступа - их назначение хранение ColdData (например бэкапов)

    *SFF Small Form Factor - это диски 2,5” Обычно это высоко-оборотистые 10-15К SAS диски объёмом 300-1200GB. Не стоит путать их с ноутбучными дисками.
    LFF Large Form Factor - это диски 3,5” Обычно низко-оборотистые 7200 диски, объёмом 2TB и более.

  8. И наконец, если у вас уже есть СХД, добавив полку вы можете увеличить не только объём, но и существенно повысить скорость работы. Ведь показатель IOPS напрямую зависит от количества дисков.

    У нас имеются полки для наиболее распространённых СХД производства NetAPP, HP, Dell, IBM.

На этом всё.
Остались вопросы - звоните, будем рады помочь.

Полки б/у
Внешние RAID & HBA б/у
Внешние кабели SAS

forpro.ru

Производительность СХД: как определить, какая система подходит бизнесу? | Журнал сетевых решений/LAN

Как узнать производительность систем хранения данных (СХД)? Существуют два подхода для ее оценки — технический и пользовательский. В первом случае производительность описывается рядом технических параметров, связанных с работой СХД. Такой подход используется в основном ИТ-специалистами. Во втором случае производительность оценивается на основании субъективных мнений пользователей относительно того, насколько быстро работает ИТ-система. Очевидно, что для реальной оценки производительности СХД этот подход не годится, но о нем не надо забывать, поскольку пользователи информационных систем видят производительность любого компонента ИТ-системы сквозь призму своих мониторов.

Итак, с точки зрения ИТ-специалиста, производительность СХД — это в первую очередь количество операций ввода-вывода в секунду (IOPS) и объем переданных мегабайтов в секунду (Мбайт/с), которые система хранения способна обеспечить при чтении и записи данных. Производительность СХД в IOPS используется для оценки нагрузки транзакционных приложений: баз данных Online Transaction Processing (OLTP), файловых хранилищ, почтовых систем и прочего. Другой технический параметр, тесно связанный с транзакционной нагрузкой, — время отклика при операциях ввода-вывода (response time). Иными словами, это время, затраченное СХД на обработку одной операции ввода-вывода и передачу ее результатов хосту.

Время отклика и раньше использовалось наряду с количеством IOPS для детального планирования конфигурации СХД. Но широкую популярность этот параметр приобрел после появления СХД, целиком построенных на базе флеш-накопителей. Основная особенность этих систем — способность обрабатывать ввод-вывод приложений со временем отклика меньше одной миллисекунды. Для ряда приложений, в частности баз данных OLTP, минимально возможное время отклика так же важно, как и IOPS.

Для оценки производительности приложений, у которых профиль нагрузки на СХД представляет собой последовательный доступ к данным, принято использовать объем передаваемых данных, выраженный в мегабайтах в секунду (Мбайт/с). Пример таких приложений — базы данных в конфигурации «хранилище данных» (Data Warehouse, DWH), приложения для обработки видеоконтента и резервного копирования.

ИЗ ЧЕГО СКЛАДЫВАЕТСЯ ПРОИЗВОДИТЕЛЬНОСТЬ

Производительность ИТ-системы в целом определяется производительностью ее отдельных компонентов: приложений, операционной системы, физического или виртуального сервера, сети передачи данных между сервером и СХД и самой СХД (см. рис. 1). Любой из этих компонентов, как правило, состоит из множества отдельных подсистем, каждая из которых способна оказывать влияние на общую производительность ИТ-системы. Так, недостаток оперативной памяти в сервере даже при наличии 100 высокопроизводительных процессорных ядер может привести к заметному снижению общей производительности ИТ-системы. Или, к примеру, неверно выбранная конфигурация дисковой подсистемы СХД старшего класса будет «тормозить» всю ИТ-систему, несмотря на то что такая СХД способна выдержать очень большую нагрузку.

Рис. 1. Производительность ИТ-системы в целом определяется производительностью ее отдельных компонентов

 

Очевидно, что производительность ИТ-системы — это не сумма показателей всех ее компонентов. Зачастую она зависит от характеристик наиболее «слабого звена». Поэтому если ставится задача повысить производительность ИТ-системы, то не всегда необходимо покупать новую СХД, устанавливать новые серверы с процессорами последнего поколения и т. п. Гораздо важнее выявить узкое место в текущей конфигурации ИТ-системы и понять, можно ли исправить ситуацию, используя имеющиеся ресурсы. Например, замена СХД на флеш-массив (All-Flash Array, AFA) может дать прирост производительности ИТ-системы на несколько десятков процентов, тогда как простая оптимизация SQL-запроса к СУБД позволит увеличить эту производительность многократно.

Если же покупка новой СХД неизбежна, нужно тщательно продумать все детали. Чтобы правильно выбрать новую СХД или спланировать модернизацию существующей, необходимо собрать все требования, предъявляемые ИТ-системой к хранению данных, основные из которых — емкость и производительность. И если вопрос «Сколько терабайтов полезной емкости вам нужно?», как правило, не вызывает проблем, то просьба указать величину необходимой производительности может многих поставить в тупик.

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

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

 

С ЧЕГО НАЧАТЬ ОЦЕНКУ ПРОИЗВОДИТЕЛЬНОСТИ?

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

Внедрение нового решения тоже, как правило, не вызывает особых трудностей: поставщики программного обеспечения обычно уже имеют готовые рекомендации по развертыванию своих систем. К примеру, у компании VMware существует понятие «шаблонного пользователя» применительно к решениям по виртуализации рабочих мест (VDI). В принятой классификации все пользователи делятся на три категории: light-пользователи несильно нагружают систему, тогда как medium- и heavy-пользователи более требовательны к ресурсам. По каждой категории подготовлены количественные характеристики: рекомендуемая емкость памяти, число процессорных ядер, IOPS, объем передаваемых мегабайтов в секунду и так далее (см. таблицу). Таким образом, зная, что необходимо развернуть VDI-систему на 1000 пользователей, специалисты заранее могут оценить, какие ИТ-ресурсы для этого потребуются.

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

 

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

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

КАК ИСПОЛЬЗОВАТЬ ДИСКОВЫЕ РЕСУРСЫ СХД С УМОМ

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

Каким образом достигается экономия? В основу многоуровневого хранения положен следующий факт: данные, хранящиеся на СХД, в большинстве случаев востребованы неравномерно. Так, в приложении, которое собирает и накапливает, скажем, данные о погоде, активно используемых — или, в терминологии многоуровневого хранения, «горячих» — не более 5–15% от общего объема. Это связано с тем, что свежие данные запрашиваются намного чаще, чем, например, данные пятилетней давности.

Для хранения «горячих» данных всегда рекомендуется использовать высокопроизводительные диски. Обращение к оставшимся «холодным» данным происходит гораздо реже, и потому для их хранения лучше задействовать более дешевые и емкие, но менее производительные диски SAS или NL-SAS. При этом система хранения автоматически перераспределяет активные и неактивные данные между соответствующими быстрыми и медленными уровнями хранения (см. рис. 3).

Рис. 3. Многоуровневое хранение

 

Таким образом, мы получаем дисковый пул, производительность которого чуть меньше производительности самого быстрого уровня хранения в нем, но общая стоимость дисков (с учетом лицензии на многоуровневое хранение для СХД) оказывается существенно ниже, чем если бы в дисковом пуле использовались только высокопроизводительные диски.

ДЛЯ КАКИХ ЗАДАЧ ПОДОЙДУТ МНОГОУРОВНЕВЫЕ ПУЛЫ?

Основной критерий выбора многоуровневого хранения, как уже было сказано, — неравномерность использования данных. Наиболее часто многоуровневое хранение используется с базами данных OLTP и виртуальными средами, построенными на основе VMware и Microsoft Hyper-V. Однако необходимо отметить, что универсальных рецептов, гарантирующих, что этот подход будет эффективным абсолютно для всех решений, не существует. Если у компании есть сомнения в правильности применения многоуровневого хранения, она всегда может протестировать свою ИТ-систему на конкретной системе хранения данных и оценить ее эффективность.

Алексей Силин, консультант-эксперт компании Hitachi Data Systems

Производительность СХД: как определить, какая система подходит бизнесу?

Поделитесь материалом с коллегами и друзьями

www.osp.ru

Как выбрать СХД для защиты критически важных приложений

2136 / Фото: ru.depositphotos.com

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

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

«ИТ-подразделения хотели бы определять ресурсы для приложений с той же гибкостью, с которой это возможно в публичном облаке, — комментирует Кирилл Ордынец, ведущий инженер отдела серверов и систем хранения данных КОМПЛИТ. — При этом для устойчивой и высокоскоростной работы критически важных приложений они сильно завязаны на системы хранения данных уровня Tier 0. В организациях понимают, что при переносе таких приложений в облако снижаются возможности контроля и производительность. Подобные компромиссы, как правило, недопустимы, поэтому приходится отказываться от гибкости в пользу надежности и высокой скорости работы систем хранения данных».

Но теперь есть платформа, объединяющая в себе и гибкость облачных хранилищ, и надежную быструю работу hi-end-систем хранения данных. Это HPE Primera от Hewlett Packard Enterprise, в которой сочетаются надежность и производительность архитектуры HPE 3PAR, простота управления HPE Nimble и автоматизированная база знаний HPE InfoSight для обеспечения предсказуемых SLA.

Модульная архитектура ОС HPE Primera также позволяет производителю постоянно дополнять функционал СХД

Новую платформу можно будет протестировать в демоцентре системного интегратора КОМПЛИТ. Специалисты компании рассказали нам, что ожидать от нового продукта, каковы его особенности и возможности для бизнеса.

Мгновенный доступ к данным, организованный как сервис

В системе хранения данных HPE Primera работа с ресурсами для приложений может быть организована как предоставление облачных сервисов по запросу, что достигается прежде всего за счет упрощения процедур управления жизненным циклом СХД. Этот подход позволил на 93% сократить затраты времени на развертывание, управление и аппаратное расширение Primera по сравнению с 3PAR.

Свой вклад в упрощение работы с HPE Primera вносят:

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

В структуре ОС HPE Primera все важные функциональные модули организованы как отдельные контейнеры. Эти отдельные модули можно запускать, обновлять или перезагружать независимо от других служб. Таким образом систему можно обновлять помодульно и делать это без перезагрузки контроллеров для большинства обновлений. В отличие от большинства систем хранения данных уровня Tier 0 с монолитной архитектурой ОС, для которых обновления операционной системы затрагивают весь стек ПО и несут с собой потенциальную угрозу стабильной работе, обновления HPE Primera затрагивают только определенные сервисы и не оказывают влияния на систему в целом.

Модульная архитектура ОС HPE Primera также позволяет производителю постоянно дополнять функционал СХД, при этом не требуя от пользователя покупки каких-либо дополнительных лицензий на новые возможности. HPE Primera поставляется сразу со всеми лицензиями на настоящий и будущий функционал, кроме лицензии на шифрование данных. Это сделано прежде всего для защиты инвестиций заказчиков, так же, как и возможность обновления аппаратной базы — контроллеры, которые будут выходить в будущем, будут совместимы с текущим шасси, что позволит прямо на ходу заменять старые контроллеры на новые и получать прирост производительности. Доступна также «подписка» на обновление контроллеров Timeless Storage — c ней можно заранее приобрести право на обновление через 3 года с гарантией ускорения работы СХД.

В структуре ОС HPE Primera все важные функциональные модули организованы как отдельные контейнеры

И, наконец, весомый вклад в защиту инвестиций заказчиков в HPE Primera вносят гарантии эффективной емкости (HPE Store More Guarantee) и высокой доступности (100% Availability Guarantee), по которым производитель несет материальную ответственность за работу функций компактизации данных и за незапланированные простои при соблюдении заказчиком минимальных условий.

Ориентированная на приложения надежность в работе

«По статистике, — рассказывает Кирилл Ордынец, — большинство проблем с доступностью данных происходит по причинам, лежащим за пределами системы хранения данных: в сетях SAN, гипервизоре, гостевых ОС и т.д. Поэтому наращивание средств для повышения надежности только СХД не может служить полной гарантией бесперебойной работы критически важных приложений. Исходя из этого, в построении HPE Primera применен подход, в котором обеспечение надежности работы ЦОДа традиционными способами, дополнено интеграцией с системой предсказательной аналитики HPE InfoSight».

HPE Primera представляет собой высоконадежное решение Tier 0, в котором полностью активная внутренняя архитектура без единых точек отказа совмещается с модульной ОС, для которой обновления и перезапуски отдельных сервисов не влияют на работу в целом. Кроме того, архитектура HPE Primera дополнена репликацией с автоматическим, прозрачным для приложений переключением между площадками. И это только часть того подхода, который применен в СХД для защиты работы приложений.

В дополнение к присущим традиционным СХД методам и подходам в HPE Primera использованы технологии машинного обучения. Система HPE InfoSight собирает и анализирует сведения со всего стека инфраструктуры и сравнивает их с похожими инфраструктурами в глобальной базе. На основании собранной информации о внешних причинах сбоя и недоступности данных аналитическая система дает рекомендации по устранению проблем в настоящем и будущем. Исходя из сведений о работе и хранимых на массиве объемах данных HPE InfoSight предоставляет прогнозы загрузки системы и ее емкости, упрощая планирование апгрейдов по объему хранения и/или контроллеров СХД.

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

Препятствием к тому, чтобы консолидировать несколько критически важных приложений на одной системе хранения данных, часто становится такой важный параметр, как время отклика при операциях ввода-вывода. В общих условиях сложно организовать работу нескольких приложений так, чтобы у каждого из них было гарантированное время отклика, всегда возможна ситуация, когда одно из приложений начнет перетягивать ресурсы на себя. Таким образом, чтобы объединить работу нескольких критически важных приложений на базе одной СХД, необходимы механизмы, обеспечивающие гарантированно малое время отклика для каждого из них.

Для совместной работы приложений с малым временем отклика в HPE Primera представлен комплекс решений для так называемого прогнозного ускорения. Это, во-первых, полностью активная внутренняя архитектура, в которой данные всех томов доступны через все порты контроллеров системы хранения данных. Во-вторых, система со всеми активными контроллерами означает, что внутренние ресурсы будут сбалансированы для оптимальной производительности.

Архитектура системы хранения данных изначально построена с поддержкой NVMe и SCM (Storage Class Memory). Это позволяет задействовать такие преимущества NVMe, как устранение лишних циклов ЦПУ для синхронизации данных между потоками за счет неблокируемого дизайна NVMe, и дает безграничные возможности параллельной обработки запросов. А поддержка нового типа накопителей SCM (главным образом, Intel Optane) позволяет в разы сократить задержки на доступ к данным и получить реальные выгоды от кэширования чтения на такие накопители.

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

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


cnews.ru

Выбор сетевого накопителя

Содержание

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

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

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

Технические характеристики

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

Число отсеков для накопителей

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

Первой характеристикой, непосредственно связанной с числом отсеков, является максимальный допустимый объем хранилища. Он, в свою очередь, определяется параметрами жестких дисков. На момент подготовки статьи для формата 3,5″ на рынке были представлены модели на 8 TB, а для формата 2,5″ (тонкого) — 2 ТБ. Кроме того, могут быть определенные ограничения со стороны аппаратного или программного обеспечения сетевых накопителей, так что наиболее точный вариант ответа на этот вопрос — свериться с официальными списками совместимости на сайте производителя устройства.

Второй существенный момент — возможность организации отказоустойчивых массивов. Накопитель с одним диском не поддерживает такие режимы. Если же отсека два, то можно создать RAID1 (зеркало), так что отказ одного из дисков не приведет к потере данных. Правда цена этого достаточно высока — полезный объем этой конфигурации равен объему одного диска. Более эффективно можно решить вопрос в четырехдисковом устройстве — здесь поддерживается режим RAID5, требующих трех или более дисков. При этом «потери» составят один диск. То есть если установлено три винчестера по 2 ТБ, то полезный объем отказоустойчивого массива — 4 ТБ, а если четыре по 3 ТБ — то полезный объем будет 9 ТБ.

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

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

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

Также относительно недавно были анонсированы экзотические устройства для работы с твердотельными дисками компактных форматов (обычные с корпусами 2,5″ конечно можно использовать также как и винчестеры).

Платформа

Некоторое время назад наиболее популярные модели домашних сетевых накопителей были основаны на чипах с архитектурой ARM от Marvell, а высокопроизводительные устройства работали на процессорах Intel с архитектурой x86. Сегодня данное положение дел в целом сохраняется, хотя конечно уровень вычислительной производительности заметно вырос.

На самом деле, если говорить о популярных задачах, включая хранение файлов и резервное копирование, то они мало зависят от модели процессора. По сути, даже одно ядро ARM с частотой 1 ГГц способно полностью задействовать на них гигабитное сетевое подключение, так что гнаться за мощностью имеет смысл только в том случае, если вы знаете зачем она вам нужна. Среди наиболее распространенных задач, работающих в реальном времени, можно отметить видеонаблюдение, работу с зашифрованными данными, обслуживание VPN-подключений, IP-телефония, сложные веб-сайты, виртуализация. Но есть и фоновые приложения, которым тоже не помешала бы дополнительная производительность, в частности это индексация медиафайлов и создание превью для фотографий и видео.

Явную зависимость производительности от объема оперативной памяти тоже найти непросто. Для «обычных» вариантов использования сегодня будет вполне достаточно и 512 МБ, да и бюджетные устройства с 256 МБ смогут реализовать практически все. Наибольший эффект от наличия нескольких гигабайт будет при работе с системами виртуализации, которые сегодня начали появляться в моделях верхнего уровня.

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

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

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

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

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

Порты для внешних устройств

Современные сетевые накопители являются многофункциональными серверами и к ним можно подключать внешние устройства. Чаще всего речь идет о USB версий 2.0 или 3.0 для расширения дискового пространства внешними накопителями. Этот же вариант используется и для резервного копирования с NAS или на NAS.

Второй по популярности сценарий для USB — подключение ИБП, позволяющий организовать мониторинг и автоматическое безопасное выключение накопителя при длительном отсутствии напряжения и восстановление работоспособности при его появлении.

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

Среди более экзотических вариантов упомянем вывод звука через USB-аудиокарту, Bluetooth-адаптеры, беспроводные адаптеры Wi-Fi, веб-камеры и устройства ввода. Возможности этих конфигураций целиком определяются программным обеспечением NAS.

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

Выход HDMI

Некоторые производители, в частности QNAP и Thecus, устанавливают на своих устройствах порт HDMI. Наиболее интересным сценарием работы с ним является реализация медиаплеера на базе сетевого накопителя. Обычно для этого используется специальная версия программного обеспечения HTPC — известной программы Kodi (ранее XBMC). Вам остается только продумать способ управления (ИК-пульт, клавиатура, мышка, специальная утилита для смартфона).

Учитывая, что сетевые накопители интересны и тем, что могут без снижения эффективности быть установлены в любой точке домашней локальной сети, использование для них тумбы около телевизора обычно сложно считать хорошим вариантом как из-за шума, так и необходимости иметь дополнительные сетевые порты, да и ИБП будет неудобно подключать. Исключение составляет, пожалуй, только QNAP HS-251, имеющий красивый «плоский» корпус без вентиляторов.

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

Другие параметры

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

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

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

На передней панели накопителя обычно расположены индикаторы и кнопки, а также порт USB. Первые могут быть полезны с точки зрения определения состояния устройства, однако удобнее настроить встроенную систему уведомлений по электронной почте или push-технологии для смартфона. Часто включать-выключать NAS тоже не требуется, поэтому и кнопки не играют существенной роли. Исключение составляет использование портов USB для оперативного подключения носителей и обмена данными с ними.

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

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

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

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

Программные характеристики

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

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

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

Веб-интерфейс

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

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

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

Кроме того, заметим, что обычно и веб-интерфейс и основные возможности прошивки практически одинаковы для всех моделей в линейке

Конфигурация дисковых массивов

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

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

Сетевой доступ к файлам

Многие устройства поддерживают все распространенные протоколы сетевого доступа к файлам. Формально можно сказать, что SMB/CIFS используется в Windows, AFP в OS X, а NFS в Linux, но на самом деле многие операционные системы способны работать не только со своими «родными» вариантами, но и с другими. Однако в общем случае считается, что именно описанные выше пары наиболее эффективны в каждом случае. Например, AFP позволяет реализовать беспроблемную работу сервиса резервного копирования Time Machine в OS X.

Кроме этих, часто встречается реализация сервера FTP (в том числе и с шифрованием), что позволяет обмениваться файлами через интернет. В некоторых случаях может оказаться полезным и работа по протоколу WebDAV.

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

Сетевые настройки

Наиболее популярным способом подключения накопителя к домашней сети сегодня является гигабитный сетевой порт, обеспечивающий скорости чтения и записи примерно до 110 МБ/с. Если ваш роутер или клиент не поддерживают гигабит, а работают только на скорости 100 Мбит/с, то производительность будет существенно ниже, что придется учитывать при передаче больших объемов данных.

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

Мультимедиа

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

Но если вы хотите смотреть видео на игровых приставках или «умных» телевизорах без использования дополнительного оборудования, то здесь не обойтись без сервера DLNA. К сожалению, даже при наличии сертификатов, могут встречаться проблемы совместимости между сервером и клиентом. Здесь может пригодиться возможность установки других медиасерверов, например Plex или Twonky.

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

Безопасность

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

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

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

Журналы и уведомления

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

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

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

Внешние устройства

Как мы писали выше, возможности использования внешних устройств зависят не столько от наличия аппаратных интерфейсов, сколько от программного обеспечения. Наиболее распространенным вариантом является универсальные порты USB. Многие модели сетевых накопителей позволяют использовать их для связи с ИБП (стоит проверить список совместимости на наличие доступных в магазинах моделей), а также для внешних дисков, которые могут быть подключены как новые общие папки или использоваться для резервного копирования. Обратить внимание здесь стоит на поддерживаемые файловые системы. Хотя обычно у всех есть и NTFS (для совместимости) и EXT3/4 (для скорости).

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

Встречаются также и такие редкие варианты как подключение аудиокарты для трансляции музыки или веб-камеры для организации видеонаблюдения.

Резервное копирование и синхронизация

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

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

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

Удаленный доступ

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

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

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

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

Мобильные приложения

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

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

Дополнительные сервисы

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

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

  • Система автономной загрузки файлов по протоколам HTTP/FTP/Bittorrent;
  • Система видеонаблюдения для IP-камер;
  • Фотоальбом;
  • Синхронизация/резервное копирование файлов на облачные сервисы;
  • Медиасерверы DLNA;
  • IP-телефония;
  • Почтовые серверы;
  • Сервер VPN;
  • Виртуализация;
  • Различные варианты CMS и блогов;
  • Программы для домашней автоматизации.

Набор доступных пакетов зависит от аппаратной платформы накопителя. Некоторые производители приводят на своих веб-сайтах соответствующие списки по моделям.

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

Другие параметры

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

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

Мы не стали отдельно выделять такую характеристику как стоимость, но ее важность, конечно, оспаривать сложно.

Заключение

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

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

Если попробовать ограничить число параметров до трех, то мы бы остановились на числе отсеков для дисков, производителе (это определяет возможности прошивки) и стоимости.

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

www.ixbt.com

Неочевидные особенности работы СХД / Habr

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

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

Почему VMWare? Все просто, я являюсь специалистом по данной среде виртуализации, имею статус VCP5. Продолжительное время работал с крупными заказчиками и имел доступ к их системам.

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

Что такое виртуализация (в области серверов)? Это некая программно-аппаратная система, позволяющая на логическом уровне отделить вычислительные ресурсы от аппаратной части. В классическом виде на одном сервере может работать только одна операционная система, управляющая данным сервером. Все вычислительные ресурсы отданы этой операционной системе, и она ими монопольно владеет. В случае виртуализации, у нас добавляется прослойка программного обеспечения, которая позволяет эмулировать некоторую часть вычислительных ресурсов сервера в виде изолированного контейнера, и таких контейнеров (виртуальных машин) может быть множество. В каждый контейнер может быть установлена собственная операционная система, которая, возможно, и подозревать не будет, что её аппаратный сервер на самом деле является виртуальным контейнером. Подобная прослойка программного обеспечения называется гипервизором, средой для создания контейнеров, или виртуальных серверов.

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

Все дисковые системы, по сути, характеризуют 3 характеристики:
1. Ширина канала передачи данных
2. Максимальное количество операций ввода-вывода
3. Величина средней задержки при максимально допустимой нагрузке

1. Ширина канала обычно определяется интерфейсом подключения системы хранения и производительностью самой подсистемы. На практике средняя нагрузка по ширине крайне незначительная и редко превышает 50…100 мегабайт в секунду даже для группы из 20-30 виртуальных серверов. Конечно, бывают и специализированные задачи, но мы сейчас говорим о средней температуре по больнице. Практика указывает именно на такие цифры. Естественно, бываю и пиковые нагрузки. В такие моменты полосы пропускания может и не хватить, поэтому при сайзинге (планировании) вашей инфраструктуры, надо ориентироваться именно на максимальные возможные нагрузки.

2. Операции ввода-вывода можно поделить на однопоточные и многопоточные. Учитывая тот факт, что современные операционные системы и приложения поголовно научились работать многопоточно, будем считать всю нагрузку многопоточной. Далее операции ввода-вывода можно поделить на последовательные и случайные. Со случайным доступом все понятно, а вот с последовательным? Учитывая нагрузку от большого количества виртуальных машин, да еще и многопоточную от каждой машины, мы в итоге получим практически полностью случайный доступ к данным. Конечно, варианты специфических случаев с последовательным доступом и малым количеством потоков возможны, но опять же, у нас рассматривается средняя температура. Наконец, операции ввода-вывода можно поделить на чтение и запись. Классическая модель говорит нам о 70% операций чтения и 30% операций записи. Возможно, так и есть для приложений внутри виртуальных машин. И ведь многие при тестировании и сайзинге принимают данную статистику за основу тестирования систем хранения. И делают огромную ошибку. Люди путают статистику доступа для приложений, и статистику доступа для дисковой подсистемы. Это не одно и то же. На практике для дисковой системы наблюдается следующее деление: порядка 30% операций на чтение и 70% на запись.

Откуда такая разница?! Она из-за работы кэшей разного уровня. Кэш может быть у самого приложения, у операционной системы виртуальной машины, у гипервизора, у контроллера, у дискового массива, наконец у самого диска. Как итог, часть операций на чтение попадает в кэш какого либо уровня и не доходит до физических дисков. А операции записи доходят всегда. Это надо четко помнить и понимать при сайзинге систем хранения.

3. Задержки, или латентность системы хранения, это время, за которое гостевая операционная система получит запрашиваемые данные с её диска. Схематично и упрощенно запрос от приложения идёт следующим образом: Приложение-Операционная система-Виртуальная машина-Гипервизор-Система хранения данных-Гипервизор-Виртуальная машина-Операционная система-Приложение. На самом деле промежуточных звеньев цепи в 2-3 раза больше, но давайте опустим глубокие технические тонкости.
Что в этой цепочке может интересовать больше всего? В первую очередь ответ самой системы хранения и работа гипервизора с виртуальной машиной. С системой хранения вроде все ясно. Если у нас SSD диски, то время тратится на чтение данных из нужной ячейки и по сути все. Латентность минимальна, порядка 1 ms. Если у нас SAS диски 10к или 15к, то время доступа к данным будет складываться из многих факторов: глубины текущей очереди, позиции головки относительно очередной дорожки, угловой позиции пластины диска относительно головки и т.д. Головка позиционируется, ждет поворота диска, когда нужные данные окажутся под ней, производит операцию чтения или записи и летит к новой позиции. Умный контроллер хранит в себе очередь доступа к данным на дисках, корректирует очередность чтения в зависимости от траектории полета головки, меняет местами позиции в очереди, пытается оптимизировать работу. Если диски в RAID массиве, то логика доступа становится еще более сложной. Например, у зеркала есть 2 копии данных на 2-х половинках, так почему бы не читать разные данные из разных локаций одновременно двумя половинками зеркала? Аналогично ведут себя контроллеры и с другими типами RAID. В итоге для скоростных SAS дисков стандартная латентность равна 3-4 ms. У медленных собратьев NL-SAS и SATA этот показатель ухудшается до 9 ms.

Теперь рассмотрим звено цепи гипервизор-виртуальная машина. У виртуальных машин контроллеры жестких дисков тоже виртуальные, обычно это SCSI устройства. И общается гостевая операционная система со своим диском тоже ISCSI командами. В момент обращения к диску виртуальная машина блокируется гипервизором и не работает. В это время гипервизор перехватывает SCSI команды виртуального контроллера, после чего возобновляет работу виртуальной машины. Теперь уже сам гипервизор обращается к файлу с данными виртуальной машины (файлу диска виртуальной машины) и производит с ним необходимые операции. После этого гипервизор опять останавливает виртуальную машину, снова генерирует SCSI команды для виртуального контроллера и от имени диска виртуальной машины дает ответ на недавний запрос гостевой операционной системы. Данные операции подделки ввода-вывода требуют порядка 150-700 тактов центрального процессора физического сервера, то есть занимают около 0.16 микросекунды. С одной стороны не так много, но с другой стороны? Что если у машины активный ввод-вывод? Допустим, 50.000 IOPS. И что если она так же интенсивно общается с сетью? Добавим сюда достаточно вероятную потерю данных из кэша процессора, который мог смениться за время ожидания подделки запросов гипервизором. Или чего доброго, поменялось исполняющее ядро. В итоге мы имеем существенное снижение общей производительности виртуальной машины, что достаточно неприятно. На практике я получал падение производительности вплоть до 40% от номинала из-за влияния гиперактивного ввода-вывода виртуальной машины по сети и дисковой системе.
Медленная работа дисковой системы колоссально сказывается на работе приложений внутри гостевых машин. К сожалению, многие специалисты недооценивают это влияние, и при сайзинге аппаратной части стараются экономить на дисковой подсистеме: пытаются ставить недорогие, большие и медленные диски, экономят на контроллерах, отказоустойчивости. Потеря вычислительной мощности приводит к неприятностям и простою. Потери на уровне дисковой системы могут привести к потере всего, в том числе и бизнеса. Помните об этом.

Однако вернемся к операциям чтения и записи, а так же особенностям работы с ними различных уровней RAID. Если принимать stripe как 100% производительности, то следующие типы массивов имеют показатели:

Операция Тип массива КПД
Чтение
RAID0 100%
RAID10 100%
RAID5 ≈90%
RAID6 ≈90%
Запись
RAID0 100%
RAID10 50%
RAID5 25%
RAID6 16%

Как мы видим, RAID5 и RAID6 имеют колоссальные потери производительности при записи. Тут нельзя забывать, что операции ввода-вывода нагружают дисковую систему совместно, и их нельзя считать по отдельности. Пример: в режиме RAID0 некая гипотетическая система имеет производительность 10.000 IOPS. Собираем RAID6, нагружаем классической нагрузкой среды виртуализации, 30% чтение и 70% записи. Получаем 630 IOPS чтения с одновременными 1550 IOPS записи. Не густо, правда? Конечно, наличие в системах хранения и контроллерах кэша в режиме записи write-back несколько увеличивает производительность, но у всего есть пределы. Считать IOPS надо правильно.

Пара слов о надежности, которые уже неоднократно были сказаны. При выходе из строя больших и медленных дисков наступает процесс ребилда массива (мы ведь позаботились о горячей замене?). На дисках 4ТБ процесс ребилда RAID 5 и 6 занимает около недели! А если нагрузка на массив велика, то и того больше. Так же процесс ребилда связан с резким ростом нагрузки на диски массива, что повышает вероятность сбоя еще одного диска. В случае с RAID 5 это приведет к безвозвратной потере данных. В случае с RAID 6 мы сталкиваемся с высокими рисками потери третьего диска. Для сравнения, в RAID10 при ребилде массива, по сути, просто копируются данные с одной половинки зеркала (одного диска) на другую. Это гораздо более простой процесс и занимает он относительно мало времени. Для диска 4 ТБ при средней нагрузке время ребилда составит порядка 10-15 часов.

Хочется добавить, что бывают в природе и умные системы хранения типа Dell Compellent SC800, которые имеют очень гибкий подход к хранению данных на базе различных настраиваемых уровней Tier. Например, эта система может писать новые данные только на SCL SSD диски в режиме RAID10, после чего, в фоновом режиме, перераспределит блоки данных на другие типы дисков и уровни RAID в зависимости от статистики обращения к этим блокам. Системы эти достаточно дороги и нацелены на специфического потребителя.

Подводя итоги, остается определить следующие тезисы:
— Система хранения под виртуализацию должна быть быстрой и надежной, с минимальными задержками
— При проектировании среды виртуализации на систему хранения необходимо закладывать порядка 40% всего бюджета аппаратной части
— При сайзинге системы хранения, в общем случае, стоит ориентироваться на RAID10
— Бэкапы спасут мир!

habr.com

сравниваем 7 решений / ГК ЛАНИТ corporate blog / Habr

В этой статье я кратко расскажу о программно-определяемых хранилищах (Software-Defined Storage, SDS) и о возможностях их применения, которые они дают при построении ИТ-инфраструктуры. В конце статьи вас ждет сравнение семи SDS-решений. Я протестировал их, когда мы с коллегами из «Онланты» прорабатывали варианты развития инфраструктуры облака OnCloud.ru. Надеюсь, что сравнительная таблица сэкономит вам кучу времени и сил при выборе продукта.


Источник

Я работаю системным инженером группы облачной интеграции компании «Онланта». Одно из направлений моей деятельности — это исследовательские работы (R&D) по изучению и сравнению новых технологий, которые могли бы помочь нам повысить качество и снизить стоимость облачных услуг OnCloud.ru, предоставляемых «Онлантой». С результатами такого сравнения SDS-решений вы познакомитесь в этой статье.

Тренд к снижению стоимости владения ИТ-инфраструктурой


В крупных организациях системы хранения данных занимают значительную долю стоимости ИТ-инфраструктуры (по оценкам специалистов – до 25%). Эта цифра может существенно вырасти. Причины – рост объема данных и увеличение потребности в емкостях систем хранения данных (СХД), в том числе из-за законов, которые обязывают эти данные хранить. В то же время компании активно стараются экономить ИТ-бюджеты, что вынуждает их находиться в постоянном поиске наиболее выгодных технологических решений, которые бы позволили сократить эти расходы не в ущерб качеству сервиса. Это же относится к хранению и обработке данных.

Требования заказчиков к снижению стоимости владения ИТ-инфраструктурой заставляют поставщиков инвестировать в разработки и предлагать новые технологии. Одна из них — программно-определяемые системы хранения данных (Software-Defined Storage, SDS). Компании начинают задумываться о внедрении SDS, когда процедуры работы с данными становятся неэффективными и их поиск отнимает много времени.


Источник

Концепция SDS позволяет получить такие преимущества, как:

  • абстрагирование от нижнего уровня (аппаратной платформы),
  • масштабируемость,
  • упрощенная инфраструктура хранения,
  • низкая стоимость решений.

Благодаря технологиям SDS можно значительно снизить стоимость СХД и их администрирования. По прогнозам Gartner, к 2020 году 70–80% неструктурированных данных будут храниться на недорогих системах, управляемых с помощью SDS, а уже к 2019 году 70% существующих массивов хранения станут доступны в полностью программной версии.

Когда и зачем нужна SDS


ПО управления СХД должно обеспечивать гибкую организацию хранения данных, а также:
  • дедупликацию,
  • репликацию данных,
  • динамическое выделение емкости,
  • снимки данных,
  • соблюдение политик хранения.


Источник

SDS определяют в Storage Networking Industry Association (SNIA, Ассоциация производителей и потребителей систем хранения) как виртуализированную среду хранения данных с интерфейсом управления сервисами, которая должна включать в себя:

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

Отмечу, что для SDS нужен стандартизированный интерфейс управления – такой, как SNIA Storage Management Initiative Specification (SMI-S). Он является составной частью концепции программно-определяемых дата-центров (SDDC). Эта программная логика облачной инфраструктуры хранения и облачных аппаратных платформ может быть элементом и традиционных ЦОД. Сервисы хранения и обработки данных могут выполняться на серверах, специализированных устройствах хранения (storage appliance) или на обеих этих платформах, устраняя традиционные границы.

Сравниваем SDS-решения


Software-Defined Storage предлагают многие вендоры:
  • Dell EMC (решения Dell Nexenta, EMC ScaleIO),
  • HPE (решение StoreVirtual VSA),
  • IBM (решение Spectrum Storage),
  • NetApp (решение ONTAP Select),
  • VMware (решение vSAN),
  • Red Hat (решение Red Hat Storage),
  • StoneFly (решения SCVM, SDUS),
  • DataCore (решение SANsymphony),
  • SwiftStack,
  • Pivot3 и др.

Уточню, что решение RedHat Storage представлено двумя продуктами: RedHat Ceph Storage и RedHat Gluster Storage (RH Storage Server). Здесь они подразумеваются оба, но в приведенном ниже сравнении они не участвовали, так как значительно отличаются от других упомянутых решений.
Ceph — не совсем коробочный продукт. Его использование без штата разработчиков достаточно затруднительно, что сделало его неинтересным для нашей компании. Поэтому этого решения нет в сравнительной таблице.

Условно все SDS-решения можно разделить на три категории:

  • классические (CEPH, Red Hat Storage Server, EMC ScaleIO),
  • на основе традиционных систем хранения (NetApp ONTAP Select, HPE StoreVirtual VSA),
  • в составе вычислительных комплексов (VMware vSAN).

Некоторые производители предлагают как комплексные решения, так и программную часть (Huawei, Dell EMC). Это позволяет гибко подходить к подбору продуктов и использовать унаследованное «вычислительное» оборудование для решения менее ресурсоемких задач хранения данных. Еще одной заслугой SDS стала возможность применения в некоторых классических СХД виртуализации дисковых массивов.

Решения архитектурно строятся по двум принципам:

  • слабо связанные,
  • распределенные (без общих элементов).

В первом случае отказоустойчивость обеспечивается за счет распределенных копий данных, но из-за избыточности коммуникаций между узлами (нодами) снижается скорость записи. Критичным местом является сеть передачи данных, поэтому такие решения обычно реализованы на основе InfiniBand. По такому принципу построены решения VMware vSAN, HPE StoreVirtual VSA, Dell EMC ScaleIO.

В системах без общих элементов данные записываются на один узел, а потом с заданной периодичностью копируются на другие для обеспечения отказоустойчивости. При этом записи не являются транзакционными. Такой подход наиболее дешев. Чаще всего в качестве интерконнекта в нем используется Ethernet. Данная архитектура удобна с точки зрения масштабируемости. Яркий ее представитель — CEPH.

Сейчас многие компании занимаются разработкой как программной SDS (например, Atlantis Computing, Maxta, StarWind, DataCore Software, Sanbolic, Nexenta, CloudByte), так и выпуском комплексных решений (Dell EMC, IBM) или специализированных устройств (Tintri, Nimble, Solidfire).

Источник

Из наиболее известных на рынке мы выбрали для сравнения семь решений, которые интереснее всего для задач «Онланты». Это:

  • VMware vSAN,
  • HPE StoreVirtual VSA,
  • NetApp ONTAP Select,
  • EMC ScaleIO,
  • Huawei Fusion Storage,
  • StarWind Virtual SAN,
  • Datacore SANsymphony.

В этой таблице мы сравнили их основные характеристики.


Кликните, чтобы увеличить таблицу

Инструмент будущего


Технология SDS начала развиваться еще в начале 2000-х, но пока не смогла заменить классические СХД по целому ряду причин — сейчас мы их обсуждать не будем. Но производители активно занимаются развитием своих продуктов и интерес к технологиям SDS растет. По нашим оценкам, в ближайшее время они станут тем инструментом, который позволит сокращать стоимость ИТ-инфраструктуры при росте потребности в увеличении емкости СХД.Источник

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

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

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

Если кто-то из читателей сочтёт возможным поделиться какой-либо дополнительной информацией по обсуждаемому предмету, а возможно, и рассказать о своем выборе, было бы очень интересно.

habr.com

Анализ утилизации СХД / Habr

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

Для начала определимся с терминологией. Есть несколько терминов и аббревиатур близких по смыслу: СХД, дисковый массив, SAN, Storage Array или просто Storage. Попробую внести ясность.

SAN — Storage Area Network или сеть хранения данных, это совокупность оборудования осуществляющая передачу трафика между сервером и системой хранения данных.

СХД — система хранения данных или дисковый массив, оборудование на котором хранятся данные с возможностью оперативного доступа. Есть еще архивные хранилища, но здесь мы их рассматривать не будем. Аббревиатура СХД так же может употребляться как сокращение от сеть хранения данных, но среди русскоговорящих специалистов термин СХД закрепился именно за системой хранения данных.

СХД могут обеспечивать два способа доступа к данным:

  • Блочный доступ, операционная система сервера работает с СХД как с SCSI жестким диском (упрощенно).
  • Файловый доступ, операционная система сервера работает с СХД как с файловым хранилищем по протоколу NFS, SMB и тд.

Обычно к СХД обеспечивающим блочный доступ предъявляют более высокие требования к производительности, нежели к системам обеспечивающим файловый доступ, это обусловлено спецификой решаемых задач. Далее речь пойдет о СХД c блочным доступом, работающим по протоколу Fiber Channel.

Для оценки производительности СХД используют три основные метрики


  1. Service Time, часто именуемый latency или responce time, измеряется в миллисекундах и обозначает:
    • при чтении: время с момента получения СХД задания на чтение блока информации до отправки запрошенной информации.
    • при записи: время с момента получения записываемого блока информации до подтверждения о его успешной записи.
  2. IO/s — количество операций ввода вывода в секунду.
  3. MB/s — количество переданных мегабайт в секунду.

Параметры IO/s и MB/s тесно связаны между собой размером блока данных, т.е. один мегабайт информации можно записать блоками по 4k и получить 256 операций ввода-вывода, или блоками 64k и получить 16 IO.

Рассмотрим наиболее типичные проявления проблем производительности СХД по показателям Service Time, IO/s и MB/s.

Повышенный Service Time


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

Для примера, ниже графики зависимости Service Time от IOPS для двух конфигураций СХД.

ST для All flash СХД, 2 Node, 24x1.9 TB SSD, RAID 5, Random 32k, 50/50 Read/Write.

ST для классического СХД, 2 Node, 24x1.8 TB HDD, RAID 5, Random 32k, 50/50 Read/Write.

В общих случаях для All Flash СХД приемлемым считается Service time меньше 1ms, а для классических СХД до 20ms. Порог приемлемого Service time зависит от числа контроллеров, скорости дисков и конечно модели самой СХД, и может отличаться от приведенных значений.
Также нужно учитывать до какого уровня задержек дисковой подсистемы сохраняется нормальная работоспособность приложения, и всегда иметь необходимый запас.

Планка по MB/s


Чаще всего свидетельствует об исчерпании пропускной способности канала или FC адаптера.

Конкурирующие значения по MB/s или IO/s


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

Понижение IO при возрастании ST


В случае если процентное распределение размеров блока не изменилось, но при этом ST начинает повышаться, а IO падать, это может свидетельствовать об аппаратных проблемах с СХД, деградации одного из контроллеров или высокой утилизации CPU.

Утилизация CPU


Утилизация CPU контроллеров СХД в общих случаях не должна превышать 70%, если она постоянно выше 70%, то это свидетельствует об отсутствии запаса производительности СХД.
Тут нужно отметить, что СХД можно разделить на две большие группы:
  • С использованием ASIC, в таких СХД передача данных внутри массива обрабатывается отдельным высокопроизводительным чипом, а CPU остаются сервисные задачи, такие как создание и удаление дисков и снапшотов, сбор статистики и тд.
  • Без использования ASIC, в таких СХД все задачи выполняет CPU.

Утилизацию CPU нужно трактовать по-разному для СХД с ASIC и без, но в любом случае она не должна быть выше 70% при отсутствии запущенных сервисных задач.

Медленный рост IO на чтение


Такая проблема может наблюдаться в случае если СХД использует тиринг размещения данных между носителями разной скорости (например, SSD и NL SATA).

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

Какой характер нагрузки не свидетельствует о проблемах?


Пилообразный график IO

Скачки по MB

Прыгающие значения IO

Все перечисленные примеры нагрузки не свидетельствуют о каких-либо проблемах на стороне СХД. Нагрузка создается хостом подключенным к СХД и зависит от логики процессов использующих дисковое пространство.

Как определить трешхолды для Service Time, IO/s и MB/s?


Данные параметры можно рассчитать теоретически, складывая производительность дисков и считая пенальти выбранного уровня RAID, также можно воспользоваться сайзерами при наличие оных, но расчет будет очень приблизительным, поскольку не будет учитываться реальный профиль нагрузки. Для определения точных пороговых значений, свидетельствующих например о 90% загрузке СХД, необходимо провести нагрузочное тестирование при помощи специального ПО, сформировав профиль нагрузки близкий к реальному и замерить максимальные значения IO/s и MB/s. Но как быть с Service Time? Тут зависимость нелинейная. Для определения Service Time соответствующего 90% загрузке нужно просто сгенерировать 90% от максимально достигнутого значения по IO. Полученные результаты можно экстраполировать на близкие по конфигурации СХД.

Вместо заключения


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

habr.com


Смотрите также