Тип хранилища аппаратное что это
Разбираемся вместе: что такое система хранения данных
Надёжное хранение данных — задача, которую приходится решать каждому бизнесу. Но когда повышаются объёмы информации, растут и требования к надёжности хранения данных. Чтобы организовать наилучшую работу с информацией, стоит обратиться к СХД — системе хранения данных.
В материале расскажем о том, что такое и как устроены СХД, какие проблемы они решают, как классифицируются и на какие характеристики следует смотреть в первую очередь, если вы не так давно в этой отрасли.
Что такое СХД и какие проблемы она решает
СХД (Система хранения данных или Сервер хранения данных) — это устройство для хранения и управления данными, их резервного копирования. Она призвана решить типичные проблемы, связанные с растущими объёмами информации в любой организации.
Если раньше все данные могли храниться буквально на одном жёстком диске, то сейчас любая функциональная система требует отдельного хранилища – к примеру, серверов электронной почты, СУБД, домена и так далее. Поэтому с помощью СХД можно организовать децентрализацию информации (рассредоточение её по разным хранилищам).
Лавинообразный рост размера информации, который вызван, с одной стороны, ужесточением регулирования и требованием сохранять всё больше информации, связанной с ведением бизнеса. С другой стороны, ужесточение конкуренции требует всё более глубокого анализа информации о рынке, клиентах, их предпочтениях, заказах и действиях конкурентов. Но количества жёстких дисков, которые вы можете установить в конкретный сервер, не может покрыть необходимую системе ёмкость. В этом тоже может помочь СХД.
Хранение данных — не единственная функция современных СХД. Они также предлагают экономить место в хранилище с помощью дедупликации и компрессии. Компрессия позволяет системе сжимать файлы, исключая избыточную информацию, а дедупликация помогает экономить место для хранения, исключая избыточные файлы и оставляя лишь ссылки на них.
Некоторым компаниям тяжело контролировать и ограничивать доступ из-за политики безопасности предприятия. Например, касается как доступа к данным по существующим для этого каналам (локальная сеть), так и физического доступа к носителям.
Также отметим высокие затраты используемых ресурсов для поддержания работоспособности всей информационной системы предприятия, начиная от необходимости содержать большой штат квалифицированного персонала и заканчивая многочисленными недешёвыми аппаратными решениями.
Устройство СХД
Основные компоненты типичной СХД — массив жёстких дисков (HDD или SSD), кэш-память, контроллер дискового массива, внешний корпус и несколько блоков питания.
Главная фишка СХД — это скорость работы дисковой системы. Например, если ваши диски стоят внутри сервера они не будут работать с такой же производительностью, как сервер подключённый к СХД.
Какие бывают системы хранения данных
Существует классификация СХД: они делятся на файловые, блочные и объектные. Каждый вид СХД определяет в каком виде хранятся данные, способ доступа к ним, и, как результат, простоту управления и скорость доступа к данным.
Файловые
Хранят информацию в виде файлов, собранных в каталоги (папки). Файлы организуются и извлекаются благодаря метаданным, которые сообщают, где находится тот или иной файл. Условно такую систему можно представить в виде каталога.
Блочные
Данные хранятся независимо друг от друга. Каждому такому блоку присваивается идентификатор, который позволяет системе размещать каждый блок, где ей удобно. Блочные хранилища не полагаются на единственный путь к данным (в отличии от файловых хранилищ).
Объектные
Расщепляют файлы на «объекты», которые находятся в одном, общем хранилище. Оно может быть поделено на тома, каждый из которых может иметь уникальный идентификатор и подробные метаданные, которые позволяют быстро находить объекты. Подобный подход — это распределённая система.
Принцип работы СХД — NAS, SAN и DAS
Существует несколько аппаратных компонентов, программного обеспечения и протоколов, которые в конечном итоге придают решениям для хранения данных их особые свойства.
На основе классификации выше выделяют два основных типа СХД: они различаются уровнем хранения, чтения и записи данных.
О каждом из них расскажем подробнее.
NAS расшифровывается как Network Attached Storage, что можно условно перевести как сетевое хранилище. Поскольку данные обрабатываются на уровне файлов, сервер представляется NAS как сетевой сервер со своей собственной файловой системой.
Если объяснить проще — представьте себе стационарный компьютер, который подключён к домашнему роутеру. На нём хранятся фото, видео, документы и другие данные. Сетевой доступ разрешен всем пользователям — приблизительно так выглядит NAS.
NAS-хранилище может принимать разные формы. Например, к производственному серверу могут быть подключены другие серверы, виртуальные машины или так называемые дисковые станции, на которых находится другое количество съёмных жестких дисков.
Преимущества NAS:
Недостатки NAS:
DAS расшифровывается как Direct Attach Storage — прямое подключение к рабочей станции, хранилищу). Например, подключение внешнего диска по USB условно можно назвать DAS.
Из принципиальной простоты архитектуры DAS следуют её основные преимущества: доступная цена и относительная простота внедрения. Кроме того, такой конфигурацией легче управлять ввиду хотя бы того, что число элементов системы мало.
Внутри системы находится блок питания, охлаждение и RAID-контроллер, который обеспечивает надёжность и отказоустойчивость хранилища. Управляется при помощи встроенной операционной системы.
Достоинства DAS:
Недостатки DAS:
В свою очередь SAN — это сети хранения данных. Как правило они представлены в виде внешних хранилищ на нескольких сетевых блочных устройствах и реализованы в виде протокола FC (Fiber Channel) или iSCSI (Internet Small Computer System Interface). Это блочный доступ непосредственно к устройству хранения — диску или наборов дисков в виде RAID-групп или логических устройств.
Кстати, вышеупомянутый DAS может быть очень мощным и часто более дешёвым, чем SAN. Однако в то же время недостаток DAS в том, что он не может быть легко расширен — количество подключённых компьютеров ограничено физическим количеством портов SAS на DAS (обычно их всего четыре). Поэтому многие компании и учреждения предпочитают выбирать блочные хранилища, подключенные через SAN.
Преимущества SAN:
Недостатки SAN:
Как выбрать СХД?
В первую очередь нужно понимать, какие задачи она будет решать. Важно определиться с несколькими базовыми параметрами.
Тип данных
Разные типы данных требуют разной скорости доступа, технологий обработки, компрессии и так далее. К примеру, виртуальный СХД для работы с большими медиа-файлами отличается от той системы, которая будет работать с неструктурированными данными для нейросети.
Объём данных
От этого зависит выбор дисковых накопителей. Иногда можно обойтись SSD потребительского класса — если известно, что ёмкость СХД даже в худшем случае не будет превышать 300 ГБ, а скорость доступа не критична.
Отказоустойчивость
Необходимо представлять, какова стоимость потери данных за определённое время. Это поможет рассчитать RPO (Recovery-Point Objective) и RTO (Recovery Time Objective), а также избежать лишних затрат на резервное копирование. Бэкапы, бэкапы и ещё раз бэкапы.
Производительность
Если СХД закупается под новый проект (нагрузку которого сложно предугадать), то лучше пообщаться с коллегами, которые уже решали эту задачу или протестировать СХД.
Вендор
Иногда даже для ресурсоемкого сервиса подойдет бюджетное или среднеуровневое решение (StarWind, Huawei, Fujitsu). Однако у топовых производителей — NetApp, HPE, Dell EMC — линейка продуктов достаточно широкая, и сравнительно недорогие СХД здесь также можно найти. В любом случае, желательно сильно не расширять количество вендоров на одной инфраструктуре.
Если сейчас вы находитесь в поисках решения для работы с данными, арендовать выделенный web-сервер и СХД (системы хранения данных) можно в одном из наших ЦОД. Мы, со своей стороны, обеспечим сервер быстрым соединением с интернетом на скорости до 10 Гбит/сек, постоянным подключением к электричеству и поддержкой 27/7 ;).
Хранение данных. Или что такое NAS, SAN и прочие умные сокращения простыми словами
TL;DR: Вводная статья с описанием разных вариантов хранения данных. Будут рассмотрены принципы, описаны преимущества и недостатки, а также предпочтительные варианты использования.
Зачем это все?
Хранение данных — одно из важнейших направлений развития компьютеров, возникшее после появления энергонезависимых запоминающих устройств. Системы хранения данных разных масштабов применяются повсеместно: в банках, магазинах, предприятиях. По мере роста требований к хранимым данным растет сложность хранилищ данных.
Надежно хранить данные в больших объемах, а также выдерживать отказы физических носителей — весьма интересная и сложная инженерная задача.
Хранение данных
Под хранением обычно понимают запись данных на некоторые накопители данных, с целью их (данных) дальнейшего использования. Опустим исторические варианты организации хранения, рассмотрим подробнее классификацию систем хранения по разным критериям. Я выбрал следующие критерии для классификации: по способу подключения, по типу используемых носителей, по форме хранения данных, по реализации.
По способу подключения есть следующие варианты:
подключение дисков в сервере
дисковая полка, подключаемая по FC
По типу используемых накопителей возможно выделить:
Если рассматривать форму хранения данных, то явно выделяются следующие:
По реализации достаточно сложно провести четкие границы, однако можно отметить:
RAID контроллер от компании Fujitsu
пример организации LVM с шифрованием и избыточностью в виртуальной машине Linux в облаке Azure
Давайте рассмотрим более детально некоторые технологии, их достоинства и недостатки.
Direct Attached Storage — это исторически первый вариант подключения носителей, применяемый до сих пор. Накопитель, с точки зрения компьютера, в котором он установлен, используется монопольно, обращение с накопителем происходит поблочно, обеспечивая максимальную скорость обмена данными с накопителем с минимальными задержками. Также это наиболее дешевый вариант организации системы хранения данных, однако не лишенный своих недостатков. К примеру если нужно организовать хранение данных предприятия на нескольких серверах, то такой способ организации не позволяет совместное использование дисков разных серверов между собой, так что система хранения данных будет не оптимальной: некоторые сервера будут испытывать недостаток дискового пространства, другие же — не будут полностью его утилизировать:
Конфигурации систем с единственным накопителем применяются чаще всего для нетребовательных нагрузок, обычно для домашнего применения. Для профессиональных целей, а также промышленного применения чаще всего используется несколько накопителей, объединенных в RAID-массив программно, либо с помощью аппаратной карты RAID для достижения отказоустойчивости и\или более высокой скорости работы, чем единичный накопитель. Также есть возможность организации кэширования наиболее часто используемых данных на более быстром, но менее емком твердотельном накопителе для достижения и большой емкости и большой скорости работы дисковой подсистемы компьютера.
Storage area network, она же сеть хранения данных, является технологией организации системы хранения данных с использованием выделенной сети, позволяя таким образом подключать диски к серверам с использованием специализированного оборудования. Так решается вопрос с утилизацией дискового пространства серверами, а также устраняются точки отказа, неизбежно присутствующие в системах хранения данных на основе DAS. Сеть хранения данных чаще всего использует технологию Fibre Channel, однако явной привязки к технологии передачи данных — нет. Накопители используются в блочном режиме, для общения с накопителями используются протоколы SCSI и NVMe, инкапсулируемые в кадры FC, либо в стандартные пакеты TCP, например в случае использования SAN на основе iSCSI.
Давайте разберем более детально устройство SAN, для этого логически разделим ее на две важных части, сервера с HBA и дисковые полки, как оконечные устройства, а также коммутаторы (в больших системах — маршрутизаторы) и кабели, как средства построения сети. HBA — специализированный контроллер, размещаемый в сервере, подключаемом к SAN. Через этот контроллер сервер будет «видеть» диски, размещаемые в дисковых полках. Сервера и дисковые полки не обязательно должны размещаться рядом, хотя для достижения высокой производительности и малых задержек это рекомендуется. Сервера и полки подключаются к коммутатору, который организует общую среду передачи данных. Коммутаторы могут также соединяться с собой с помощью межкоммутаторных соединений, совокупность всех коммутаторов и их соединений называется фабрикой. Есть разные варианты реализации фабрики, я не буду тут останавливаться подробно. Для отказоустойчивости рекомендуется подключать минимум две фабрики к каждому HBA в сервере (иногда ставят несколько HBA) и к каждой дисковой полке, чтобы коммутаторы не стали точкой отказа SAN.
Недостатками такой системы являются большая стоимость и сложность, поскольку для обеспечения отказоустойчивости требуется обеспечить несколько путей доступа (multipath) серверов к дисковым полкам, а значит, как минимум, задублировать фабрики. Также в силу физических ограничений (скорость света в общем и емкость передачи данных в информационной матрице коммутаторов в частности) хоть и существует возможность неограниченного подключения устройств между собой, на практике чаще всего есть ограничения по числу соединений (в том числе и между коммутаторами), числу дисковых полок и тому подобное.
Network attached storage, или сетевое файловое хранилище, представляет дисковые ресурсы в виде файлов (или объектов) с использованием сетевых протоколов, например NFS, SMB и прочих. Принципиально базируется на DAS, но ключевым отличием является предоставление общего файлового доступа. Так как работа ведется по сети — сама система хранения может быть сколько угодно далеко от потребителей (в разумных пределах разумеется), но это же является и недостатком в случае организации на предприятиях или в датацентрах, поскольку для работы утилизируется полоса пропускания основной сети — что, однако, может быть нивелировано с использованием выделенных сетевых карт для доступа к NAS. Также по сравнению с SAN упрощается работа клиентов, поскольку сервер NAS берет на себя все вопросы по общему доступу и т.п.
Unified storage
Универсальные системы, позволяющие совмещать в себе как функции NAS так и SAN. Чаще всего по реализации это SAN, в которой есть возможность активировать файловый доступ к дисковому пространству. Для этого устанавливаются дополнительные сетевые карты (или используются уже существующие, если SAN построена на их основе), после чего создается файловая система на некотором блочном устройстве — и уже она раздается по сети клиентам через некоторый файловый протокол, например NFS.
Software-defined storage — программно определяемое хранилище данных, основанное на DAS, при котором дисковые подсистемы нескольких серверов логически объединяются между собой в кластер, который дает своим клиентам доступ к общему дисковому пространству.
Наиболее яркими представителями являются GlusterFS и Ceph, но также подобные вещи можно сделать и традиционными средствами (например на основе LVM2, программной реализации iSCSI и NFS).
N.B. редактора: У вас есть возможность изучить технологию сетевого хранилища Ceph, чтобы использовать в своих проектах для повышения отказоустойчивости, на нашем практическим курсе по Ceph. В начале курса вы получите системные знания по базовым понятиям и терминам, а по окончании научитесь полноценно устанавливать, настраивать и управлять Ceph. Детали и полная программа курса здесь.
Пример SDS на основе GlusterFS
Из преимуществ SDS — можно построить отказоустойчивую производительную реплицируемую систему хранения данных с использованием обычного, возможно даже устаревшего оборудования. Если убрать зависимость от основной сети, то есть добавить выделенные сетевые карты для работы SDS, то получается решение с преимуществами больших SAN\NAS, но без присущих им недостатков. Я считаю, что за подобными системами — будущее, особенно с учетом того, что быстрая сетевая инфраструктура более универсальная (ее можно использовать и для других целей), а также дешевеет гораздо быстрее, чем специализированное оборудование для построения SAN. Недостатком можно назвать увеличение сложности по сравнению с обычным NAS, а также излишней перегруженностью (нужно больше оборудования) в условиях малых систем хранения данных.
Гиперконвергентные системы
Подавляющее большинство систем хранения данных используется для организации дисков виртуальных машин, при использовании SAN неизбежно происходит удорожание инфраструктуры. Но если объединить дисковые системы серверов с помощью SDS, а процессорные ресурсы и оперативную память с помощью гипервизоров отдавать виртуальным машинам, использующим дисковые ресурсы этой SDS — получится неплохо сэкономить. Такой подход с тесной интеграцией хранилища совместно с другими ресурсами называется гиперконвергентностью. Ключевой особенностью тут является способность почти бесконечного роста при нехватке ресурсов, поскольку если не хватает ресурсов, достаточно добавить еще один сервер с дисками к общей системе, чтобы нарастить ее. На практике обычно есть ограничения, но в целом наращивать получается гораздо проще, чем чистую SAN. Недостатком является обычно достаточно высокая стоимость подобных решений, но в целом совокупная стоимость владения обычно снижается.
Облака и эфемерные хранилища
Логическим продолжением перехода на виртуализацию является запуск сервисов в облаках. В предельном случае сервисы разбиваются на функции, запускаемые по требованию (бессерверные вычисления, serverless). Важной особенностью тут является отсутствие состояния, то есть сервисы запускаются по требованию и потенциально могут быть запущены столько экземпляров приложения, сколько требуется для текущей нагрузки. Большинство поставщиков (GCP, Azure, Amazon и прочие) облачных решений предлагают также и доступ к хранилищам, включая файловые и блочные, а также объектные. Некоторые предлагают дополнительно облачные базы, так что приложение, рассчитанное на запуск в таком облаке, легко может работать с подобными системами хранения данных. Для того, чтобы все работало, достаточно оплатить вовремя эти услуги, для небольших приложений поставщики вообще предлагают бесплатное использование ресурсов в течение некоторого срока, либо вообще навсегда.
Из недостатков: могут заблокировать аккаунт, на котором все работает, что может привести к простоям в работе. Также могут быть проблемы со связностью и\или доступностью таких сервисов по сети, поскольку такие хранилища полностью зависят от корректной и правильной работы глобальной сети.
Заключение
Надеюсь, статья была полезной не только новичкам. Предлагаю обсудить в комментариях дополнительные возможности систем хранения данных, написать о своем опыте построения систем хранения данных.
Как выбрать СХД, не выстрелив себе в ногу
Введение
Пришла пора покупать СХД. Какую взять, кого слушать? Вендор А рассказывает про вендора 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 категорий:
Один из немаловажных факторов при выборе вендора — текущая среда. Сколько и каких СХД у вас уже есть, с какими СХД умеют работать инженеры. Нужен ли вам еще один вендор, еще одна точка контакта, будете ли вы мигрировать постепенно всю нагрузку с вендора А на вендора B?
Не следует плодить сущности сверх необходимого.
iSCSI / FC / File
По вопросу протоколов доступа нет единого мнения среди инженеров, а споры напоминают более теологические дискуссии, чем инженерные. Но в целом можно отметить следующие пункты:
FCoE скорее мертв, чем жив.
Файловый доступ также не является чем то недостойным внимания. NFS / CIFS прекрасно показывают себя в продуктивных средах и при правильном проектировании имеют не больше нареканий, чем блочные протоколы.
Гибридные / All Flash Array
Классические СХД бывают 2 видов:
Специальные СХД
Помимо СХД общего назначения, ориентированных прежде всего на оперативную обработку данных, существуют специальные СХД с ключевыми принципами, в корне отличающимися от привычных (низкая задержка, много IOPS):
Данные системы предназначены под хранение и обработку медиа-файлов, отличающихся большим размером. Соотв. задержка становится практически неважной, а на первый план выходит способность отдавать и принимать данные широкой полосой в много параллельных потоков.
Дедуплицирующие СХД для резервных копий.
Поскольку резервные копии отличаются редкой в обычных условиях похожестью друга на друга (средняя резервная копия отличается от вчерашней на 1-2%), данный класс систем крайне эффективно упаковывает записанные на них данные в рамках достаточно небольшого количества физических носителей. Например, в отдельных случаях коэффициенты компрессии данных могут достигать 200 к 1.
В этих СХД нет привычных томов с блочным доступом и файловых шар, а более всего они напоминают огромную базу данных. Доступ к объекту, хранящемуся в подобной системе, осуществляется по уникальному идентификатору, либо по метаданным (например все объекты формата JPEG, с датой создания между XX-XX-XXXX и YY-YY-YYYY).
Не так часто встречаются в России на сегодня, но упомянуть о них стоит. Назначение таких СХД — гарантированное хранение данных для соответствия политикам безопасности или требованиям регуляторов. В некоторых системах (например EMC Centera) была реализована функция запрета на удаление данных — как только ключ повернут и система перешла в данный режим, ни администратор, ни кто либо другой физически не могут удалить уже записанные данные.
Фирменные технологии
Flash cache
Flash Cache – общее название для всех фирменных технологий использования флэш-памяти в качестве кэша второго уровня. При использовании флэш кэша СХД как правило рассчитывается для обеспечения с магнитных дисков установившейся нагрузки, в то время как пиковую обслуживает кэш.
При этом необходимо понимать профиль нагрузки и степень локализации обращений к блокам томов хранения. Флэш кэш – технология для нагрузок с высокой локализацией запросов, и практически неприменима для равномерно нагруженных томов (как например для систем аналитики).
На рынке доступны две реализации флэш кэша:
Tiering
Многоуровневое хранение (тиринг) — технология объединения в единый дисковый пул уровней с разной производительностью, как например SSD и HDD. В случае ярко выраженной неравномерности обращений к блокам данных система сможет автоматически отбалансировать блоки данных, переместив нагруженные на высокопроизводительный уровень, а холодные, наоборот, на более медленный.
Гибридные системы нижнего и среднего классов используют многоуровневое хранение с перемещением данных между уровнями по расписанию. При этом размер блока многоуровневого хранения у лучших моделей составляет 256 МБ. Данные особенности не позволяют считать технологию многоуровневого хранения технологией повышения производительности, как ошибочно считается многими. Многоуровневое хранение в системах нижнего и среднего классов – это технология оптимизации стоимости хранения для систем с выраженной неравномерностью нагрузки.
Snapshot
Сколько мы бы не говорили о надёжности СХД, существует множество возможностей потерять данные, не зависящие от аппаратных проблем. Это могут быть как вирусы, хакеры или любое другое, непреднамеренное удаление/порча данных. По этой причине, резервное копирование продуктивных данных является неотъемлемой частью работы инженера.
Снапшот — это снимок тома на какой то момент времени. При работе большинства систем, таких как виртуализация, БД и тд. нам необходимо снять такой снимок, из которого мы будем копировать данные в резервную копию, при этом наши ИС смогут спокойно продолжать работать с этим томом. Но стоит помнить — не все снапшоты одинаково полезны. У разных вендоров, разные подходы к созданию снапшотов, связанные с их архитектурой.
CoW (Copy-On-Write). При попытке записи блока данных его оригинальное содержимое копируется в специальную область, после чего запись проходит нормально. Таким образом предотвращается повреждение данных внутри снапшота. Естественно все эти «паразитные» манипуляции с данными вызывают дополнительную нагрузку на СХД и по этой причине вендоры с подобной реализацией не рекомендуют использовать более десятка снапшотов, а на высоконагруженных томах не использовать их вообще.
RoW (Redirect-on-Write). В данном случае, оригинальноый том натурально замораживается, а при попытке записи блока данных СХД пишет данные в специальную область в свободном пространстве, изменяя местоположение данного блока в таблице метаданных. Это позволяет уменьшить количество операций перезаписи, что в итоге нивелирует падение производительности и снимает ограничения на снапшоты и их количество.
Снапшоты бывают также двух типов по отношению к приложениям:
Application consitent. В момент создания снапшота СХД дергает агента в операционной системе потребителя, который принудительно сбрасывает дисковые кэши из памяти на диск и заставляет сделать это приложение. В этом случае при восстановлении из снапшота данные будут консистентны.
Crash consistent. В данном случае ничего подобного не происходит и снапшот создается как есть. В случае восстановления из такого снапшота картина идентична как если бы внезапно отключилось питание и возможна некоторая потеря данных, зависших в кэшах и так и не дошедших до диска. Такие снапшоты проще в реализации и не вызывают просадки производительности в приложениях, но менее надежны.
Зачем нужны снапшоты на системах хранения данных?
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 км).
На примере использования в среде виртуализации метрокластер позволяет создать датастор с виртуальными машинами, доступный на запись сразу из двух датацентров. В этом случае создается кластер на уровне гипервизоров, состоящий из хостов в разных физических датацентрах, подключенный к данному датастору. Что позволяет сделать следующее:
Виртуализация
Виртуализация СХД — это технически использование томов с другой СХД в качестве дисков. СХД-виртуализатор может просто прокинуть чужой том до потребителя как свой, попутно зеркалировав его на еще одну СХД, или даже создать RAID из внешних томов.
Классические представители в классе виртуализации СХД — это EMC VPLEX и IBM SVC. Ну и разумеется СХД с функцией виртуализации — NetApp, Hitachi, IBM / Lenovo Storwize.
Зачем может понадобиться?
Компрессия / дедупликация
Компресиия и дедупликаия — это те технологии, которые позволяют вам экономить дисковое пространство на вашей СХД. Стоит сразу упомянуть, что далеко не все данные подлежат компрессии и/или дедупликации в принципе, при этом некоторые типы данных жмутся и дедуплицируются лучше, а какие то — наоборот.
Компрессия и дедупликация бывают 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% ответа.
Дополнительная информация
С чем стоит ознакомиться дополнительно по мнению авторов
Книги
Форумы и чаты
Общие рекомендации
Теперь что же касается цен — вообще на СХД цены если и попадаются, то обычно это List price, от которой каждый заказчик получает индивидуальную скидку. Размер скидки складывается из большого числа параметров, так что предсказать, какую конечную цену получит именно ваша компания, без запроса к дистрибьютору просто невозможно. Но при этом, в последнее время low-end модели стали появляться в обычных компьютерных магазинах, таких как, например nix.ru или xcom-shop.ru. В них можно сразу приобрести интересующую вас систему по фиксированный цене, как любые компьютерные комплектующие.
Но хочется отметить сразу, что прямое сравнение по TB/$ не является верным. Если подходить с этой точки зрения, то наиболее дешёвым решением будет простой JBOD + сервер, что не даст ни той гибкости, ни той надёжности, которые обеспечивает полноценная, двухконтроллерная СХД. Это совершенно не значит, что JBOD гадость гадостная и пакость пакостная, просто нужно опять-таки очень чётко понимать — как и для каких целей вы будете использовать это решение. Часто можно услышать, что в JBOD нечему ломаться, там же один бэкплейн. Однако и бэкплейны бывает выходят из строя. Все ломается рано или поздно.
Итого
Сравнивать системы между собой нужно не только по цене, или не только по производительности, а по совокупности всех показателей.
Покупайте HDD только если вы уверены, что вам нужны HDD. Для низких нагрузок и несжимаемых типов данных, в ином случае, стоит обратить на программы гарантии эффективности хранения на SSD, которые сейчас есть у большинства вендоров (и они действительно работают, даже в России), но тут всё зависит от приложений и данных, которые будут располагаться на данной СХД.
Не гонитесь за дешевизной. Порой под эти скрывается множество неприятных моментов, один из которых Евгений Елизаров описывал в своих статьях про Infortrend. И что, в конечном итоге, эта дешевизна может выйти вам же боком. Не стоит забыть — «скупой платит дважды».