что такое схд с нуля

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

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

В данной статье речь пойдет об особенностях работы систем хранения данных. В принципе, данная информация относится и к физическим серверам, использующим системы хранения, но в основном речь пойдет все же про виртуализацию, и про 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
— Бэкапы спасут мир!

Источник

Российская распределенная СХД. Как все устроено

Этой весной команда «Рэйдикс» подготовила и выпустила первую версию ПО для создания распределенной блочной СХД, работающей на серверных платформах «Эльбрус-4.4» на базе микропроцессоров «Эльбрус-4С».

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

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

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

Особенности распределенной СХД

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

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

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

Сценарии применения

RAIDIX RAIN предполагает реализацию всех основных сценариев применения распределенной блочной СХД: инфраструктура облачного хранения, высоконагруженные базы данных и хранение аналитики Big Data. Также RAIDIX RAIN может составить конкуренцию традиционным СХД при достаточно высоких объемах данных и соответствующих финансовых возможностях клиента.

Публичные и частные облака

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

Базы данных

Кластер RAIDIX RAIN в all-flash конфигурации является эффективным решением для обслуживания высоконагруженных баз данных. Решение будет доступной альтернативой продуктам Oracle Exadata для Oracle RAC.

Аналитика больших данных

Совместно с дополнительным ПО возможно использование решения для выполнения аналитики больших данных. RAIDIX RAIN обеспечивает значительно более высокий уровень производительности и простоты обслуживания по сравнению с кластером HDFS.

Архитектура решения

RAIDIX RAIN поддерживает 2 варианта развертывания: выделенный (внешний или конвергентный) и гиперконвергентный (HCI, hyper-converged-infrastructure).

Выделенный вариант развертывания

В выделенном варианте кластер RAIDIX RAIN представляет собой классическую программную СХД. Решение развертывается на необходимом количестве выделенных серверных узлов (не менее 3х, сверху количество практически не ограничено), ресурсы которых полностью утилизируются для задач хранения.

Рис. 1. Выделенный вариант развертывания

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

Гиперконвергентный вариант развертывания

Гиперконвергентный вариант предполагает совместное размещение вычислительных мощностей (гипервизор и производственные VM) и ресурсов хранения (программная СХД) ЦОД на одном множестве узлов, в первую очередь это актуально для виртуальных инфраструктур. При таком подходе ПО RAIN устанавливается на каждый хост (узел) инфраструктуры (HCI) в виде виртуальной машины.

Рис. 2. Гиперконвергентный вариант развертывания

Взаимодействие узлов кластера RAIN между собой и с конечными потребителями ресурсов хранения (серверами, приложениями) осуществляется по протоколам iSCSI (IP, IPoIB), iSER (RoCE, RDMA) или NVMeOF.

Гиперконвергентный вариант развертывания даёт следующие преимущества:

Производительная отказоустойчивость

Основная ценность RAIDIX RAIN — оптимальное соотношение производительности, отказоустойчивости и эффективного использования ёмкости хранилища.

В рамках клиентской ИТ-инфраструктуры RAIDIX RAIN также привлекателен тем, что на выходе мы имеем «честный» блочный доступ, что выгодно отличает решение от большинства рыночных аналогов.

В настоящее время большая часть конкурентных продуктов показывают высокую производительность, только при использовании зеркалирования. При этом полезная ёмкость хранилища сокращается в 2 раза и более: однократная репликация данных (зеркалирование) — избыточность 50%, двукратная репликация данных (двойное зеркалирование) — избыточность 66,6%.

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

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

Требования по отказоустойчивости

Изначально RAIDIX RAIN разрабатывался с четким набором исходных требований к отказоустойчивости и доступности системы:

Возможности Erasure Coding в распределенной СХД

Основным подходом обеспечения отказоустойчивости RAIDIX RAIN является использование уникальных технологий Erasure Coding. Известные по флагманскому продукту компании EC используются и в распределенной СХД, что позволяет получить производительность сравнимую с зеркалированными конфигурациями. Это касается как случайной, так и последовательной нагрузки. При этом обеспечивается заданный уровень отказоустойчивости и значительно увеличивается полезная ёмкость, а накладные расходы составляют не более 30% сырой ёмкости хранилища.

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

В целом, RAIDIX RAIN предлагает 3 варианта помехоустойчивого кодирования:

Все варианты предполагают равномерное распределение данных по всем узлам кластера с добавлением избыточности в виде контрольных сумм (или кодов коррекции). Это позволяет провести параллели с кодами Рида-Соломона, используемыми в стандартных RAID-массивах (RAID-6) и позволяющими отработать отказ до 2х носителей. Сетевой RAID-6 работает аналогично дисковому, однако распределяет данные по узлам кластера и позволяет отработать отказ 2х узлов.

В RAID 6 при отказе 1-2 носителей внутри одного узла их восстановление происходит локально без использования распределённых контрольных сумм, минимизируя объем восстанавливаемых данных, нагрузку на сеть и общую деградацию системы.

Домены отказа

RAIN поддерживает концепцию доменов отказа (fault domain) или доменов доступности. Это позволяет отработать отказ не только отдельных узлов, но и целых серверных стоек или корзин, узлы которых логически группируются в домены отказа. Такая возможность достигается за счет распределения данных для обеспечения их отказоустойчивости не на уровне отдельных узлов, а на уровне доменов, что позволит пережить отказ всех сгруппированных в нем узлов (например, целой серверной стойки). В этом подходе кластер разбивается на независимые подгруппы (субкластера). Количество узлов в одной подгруппе не более 20, что и обеспечивает требование по отказоустойчивости и доступности. При этом количество подгрупп не ограничено.

Рис. 4. Домены отказа

Отработка любых отказов (дисков, узлов или сети) осуществляется автоматически, без остановки работы системы.

Помимо этого, все устройства кластера RAIDIX RAIN защищены от отказа электропитания подключением к бесперебойным источникам питания (UPS). Устройства, подключенные к одному UPS, называются группой отказа по питанию.

Характеристики и функциональность

Рассмотрим основные функциональные характеристики RAIDIX RAIN.
Таблица 1. Базовые характеристики RAIDIX RAIN

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

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

Возможности масштабирования

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

Рис. 5. Схема процесса масштабирования

Гибкость архитектуры

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

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

Поддержка различных типов носителей позволяют исходя из бюджета и решаемых задач строить на базе RAIDIX RAIN:
1. распределенные all-flash хранилища с беспрецедентно высокой производительностью и гарантированным низким уровнем задержек;
2. экономичные гибридные системы, удовлетворяющие большинству основных типов нагрузок.

Показатели производительности

В качестве заключения покажем немного цифр, полученных в результате тестирования RAIDIX RAIN на конфигурации NVMe-кластера из 6 узлов. Еще раз отметим, что на такой сборке (с серверами x86-64) продукт еще дорабатывается, и данные показатели не являются финальными.

Тестовое окружение

UPD: нагрузка выполнялась блоками 4КВ, последовательная — 1М, глубина очереди 32. Нагрузка запускалась на всех узлах кластера одновременно и в таблице представлен суммарный результат. Задержки не превышают 1 ms (99,9 перцентиль).

Источник

Азбука хранения данных: словарь для выбора СХД

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

Какие основные понятия необходимо знать ИТ-директору или системному администратору, принимая решение о выборе СХД – рассказывает генеральный директор компании «Аэродиск» Вячеслав Володкович.

Ответственный специалист может столкнуться со сложностями ещё на первых этапах выбора СХД – определяя, какой тип системы необходим компании. В целом СХД могут быть реализованы в трёх вариантах: DAS, SAN и NAS. Накопители DAS (Direct Attached Storages) напрямую подключаются к устройствам, управляющим их работой. Например, по такому принципу работает компьютер с жёстким диском или другим внешним устройством, хранящим данные. Однако изначально термин применялся к мейнфреймам – большим высокопроизводительным серверам.

Системы вида DAS появились первыми, но они не обеспечивали необходимую скорость передачи данных – а ещё не могли предоставить условия для их совместного использования. Поэтому сегодня более распространены два других типа СХД, а именно NAS и SAN.

NAS или Network-attached Storage – это сетевое хранилище данных; система хранения, которая предоставляет файловый доступ к сети. Здесь сервер получает доступ к сети, выполненной на определённой файловой системе. И эта файловая система уже установлена на СХД. В случае NAS доступ к сети чаще всего реализован в виде протоколов NFS (Network File System) или SMB (Server Message Block).

В свою очередь SAN – это сети хранения данных. Как правило они представлены в виде внешних хранилищ на нескольких сетевых блочных устройствах и реализованы в виде протокола FC (Fiber Channel) или iSCSI (Internet Small Computer System Interface). Чаще используется Fiber Channel – он основан на оптических сетях и способен обеспечить высокую пропускную способность и низкий уровень задержек. При этом протокол iSCSI основан на классических IP-сетях, и его внедрение связано с меньшими затратами.

Системы SAN предоставляют блочный доступ непосредственно к устройству хранения – диску или наборов дисков в виде RAID-групп или логических устройств. Такие логические устройства называются LUN или Logical Unit Number. И одно логическое устройство доступно одному серверу или кластеру серверов.

Таким образом, сервер (точнее операционная система сервера), который получает блочный доступ к системе хранения, форматирует LUN в свою файловую систему в зависимости от задач. Если он работает на ОС Microsoft Windows, то это файловая система NTFS или ReFS; если продукты VMware – файловая система VMFS. А если сервер работает на Linux, то он может воспроизводить целую «гирлянду» файловых систем Extfs, Ext2, Ext3, XFS и тому подобных.

После того, как специалист разобрался с типами СХД, а также видами доступа к данным и различными протоколами, возникает ещё один вопрос – как правильно оценить производительность системы? Здесь на помощь приходят три ключевых показателя: IOPS, то есть количество операций ввода-вывода в секунду; latencу или задержка, а также MBS – количество мегабайт в секунду.

Количество переданных мегабайт в секунду характеризует скорость потока чтения и записи данных, измеряемого в мегабайтах в секунду. А показатель IOPS (Input/Output Operations Per Second) говорит о том, какое максимальное количество операций чтения или записи может выдержать СХД в зависимости от размера блока данных. Эти операции могут быть очень разными: отличаться размерами блока и глубиной очереди, иметь случайный или последовательный характер.

Что касается показателя latency, то он используется в двух случаях: при чтении и записи информации. Для оценки задержки при чтении он показывает, какое время проходит с момента получения задания до отправки информации. А для оценки задержки при записи – сколько времени занимает весь процесс с момента получения информации до подтверждения записи.

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

Например, компания создаёт высоконагруженную транзакционную систему управления базами данных – скажем, PostgreSQL или Oracle. В таком случае необходимо воспроизвести характерную для этой СУБД нагрузку. Выполнив тест, можно понять, как примерно будет себя вести система хранения при решении задач СУБД, а также на какие показатели обращать особое внимание, каких значений они будут достигать. Для примера с транзакционными СУБД обычно подходит тест, который эмулирует случайный характер чтения и записи (как правило в соотношении 70 на 30) с небольшим блоком данных (как правило от 4-х до 64-х килобайт в секунду). Выполнив подобный тест, можно в первом приближении сделать вывод о возможности использования СХД для целей транзакционной СУБД.

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

Универсальный рецепт качественного тестирования СХД заключается в следующей формуле: выбрали задачу, узнали, как правильно её тестировать, подготовили тестовый стенд, протестировали, записали результат.

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

Однако снэпшоты не могут полностью заменить систему резервного копирования и выступают в качестве её дополнения. К примеру, если резервное копирование в компании выполняется раз в сутки, а данные были потеряны, снэпшоты позволяют более «гранулировано» подходить к восстановлению данных. При этом восстановление снэпшотов, в отличие от резервных копий, может проходить довольно быстро. Но если СХД выйдет из строя из-за внутренних проблем, снэпшоты уже не помогут – ведь они сами хранятся на ней.

В целом снэпшоты бывают двух видов: пересылка при записи или redirect on write, а также копирование при записи – copy on write. Снэпшоты вида redirect on write не снижают производительности СХД, при этом не почти не занимают дополнительного объема (они ничего не копируют). Этим они отличаются от copy on write, при которых данные копируются, что создает дополнительную нагрузку на СХД и «съедает» часть полезного объема.

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

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

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

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

Компрессия часто работает в связке с дедупликацией, устранением дублирующих блоков данных, которая также направлена на экономию пространства в системе. Приведём простой пример: секретарь компании, в которой тысяча человек, разослал всем сотрудникам письмо с PDF-файлом. Каждый сотрудник получил письмо – и в результате в хранилище может попасть тысяча копий файла. Дедупликация позволит предотвратить этот процесс, и вместо тысячи копий сохранить только один файл.

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

Конечно, это далеко не все понятия, с которыми может столкнуться системный администратор или ИТ-директор при выборе СХД. Характеристик систем намного больше; а вопросы управления и производительности – шире и сложнее. К тому же это только общие термины из мира хранения данных: без внимания остались более узкие вопросы виртуальных RAID-ов, гиперконвергенции, QOS-ов и так далее. Однако всё это другие темы – и разговор для совсем другой статьи.

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

Источник