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

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

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

Ответственный специалист может столкнуться со сложностями ещё на первых этапах выбора СХД – определяя, какой тип системы необходим компании. В целом СХД могут быть реализованы в трёх вариантах: 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-ов и так далее. Однако всё это другие темы – и разговор для совсем другой статьи.

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