Проблема лавинообразного роста данных вынуждает производителей решений по хранению данных предлагать новые технологии, позволяющие одновременно снизить накладные расходы на хранение и повысить производительность обработки, причем максимально автоматизировав все процессы. Применение автоматизированных средств, взаимодействующих с исходными данными без учета их структуры и работающих с ними приложений, выглядит как своеобразная панацея, позволяющая минимизировать вовлечение ИТ-персонала в данный процесс. С другой стороны, как мы все хорошо знаем, панацеи не существует, и специализированное средство может дать лучший результат, нежели средство общего назначения. Конечно, когда система хранения данных работает в режиме автопилота и не задает лишних вопросов, это значительно облегчает жизнь администратора. Но в этом же кроется и основной недостаток — текстовые файлы, медиаконтент и базы данных сильно отличаются по структуре и по эффективности применения классических технологий сжатия и дедупликации. Например, текстовые документы эффективно сжимаются, и если речь идет о хранении дублированных либо измененных данных нескольких версий на общем сетевом ресурсе, с которым работают несколько пользователей, то дедупликация дает отличный результат, особенно при высокой гранулярности. Однако если дедупликация проводится на уровне файлов, то это существенно снижает ее применимость — даже при незначительном изменении исходных данных получаются две различные копии, которые не будут идентифицированы системой как дубликаты и не станут соответствующим образом обрабатываться.
Для преодоления подобных ограничений предложена технология блочной дедупликации, позволяющая обнаруживать идентичные данные, даже когда в оригинал были внесены изменения. Классическим примером эффективности такого подхода является хранение последовательно измененных версий одного и того же файла. Однако неясно, что же делать с базами данных? Казалось бы, если дедупликация идет на уровне блоков данных, то все проблемы должны быть решены? Нет. Как отмечает Сергей Кузнецов в своей книге «Основы современных баз данных», при реляционном подходе к организации баз данных отношения не содержат кортежей-дубликатов, что следует из определения отношения как множества кортежей. В классической теории множеств каждое множество по определению состоит из различных элементов, а так как базы данных размещаются на носителях обычно построчно, то при анализе последовательно размещенных блоков данных количество идентичных блоков будет минимально, что приведет к низкому эффекту от дедупликации.
В этой ситуации применение технологии компрессии, особенно средствами самой базы данных, дает определенный эффект, но вряд ли радикальный. Как правило, в реальных базах данных достаточно большой процент занимают повторяющиеся данные — популярные имена, названия населенных пунктов, структурные подразделения внутри организации, должности сотрудников и т. д. Как можно их эффективно сжать, если данные хранятся построчно? Ответ лежит на поверхности — надо изменить хранение данных с построчного на поколоночное, а затем провести сжатие. В результате большинство столбцов с ограниченным множеством значений будут расположены компактно, что позволит на порядок увеличить эффективность применения алгоритмов сжатия (см. рис.).
.png "Компактное размещение по колонкам") |
| Компактное размещение по колонкам |
Такой подход был применен в системах Exadata и получил название гибридного поколоночного сжатия — Hybrid Columnar Compression (HCC), позволив получить на тестах коэффициент компрессии в десятки раз выше по сравнению с традиционными алгоритмами общего назначения. Однако это касается исключительно основной копии данных и того, каким образом можно повысить эффективность ее хранения за счет удаления повторяющихся элементов. Но копий самой базы данных должно быть существенно больше — при любой организации защиты основной копии данных, будь то единственный вычислительный узел либо разнесенный кластер, мы не застрахованы от потери данных. Даже в случае двух площадок и использования средств репликации на уровне массива либо на уровне приложения Oracle Data Guard, мы не можем обезопасить себя от потери данных при сохранении самого слабого звена — человека. Отсюда и многочисленные примеры восстановления данных из резервных копий, несмотря на применение самых комплексных методов защиты. Таким образом, по-прежнему актуальна задача хранения резервных копий на случай потери продуктивных данных.
Где хранить резервные копии? Самое простое — вместе с основными данными на одной системе хранения, учитывая, что современные массивы обладают богатым функционалом по созданию снимков и клонов. Однако это не обеспечивает защиту ни от аппаратного сбоя, ни от ошибки администратора, и требуется архитектура, предусматривающая отдельное от продуктивной копии данных хранение. Традиционно для решения этой задачи применяются три подхода: копирование данных с одной дисковой системы хранения на другую (disk to disk backup, D2D), копирование данных с дисковой системы на ленточную библиотеку (disk to tape backup, D2T), копирование данных с одной дисковой на другую дисковую с последующей архивацией резервных копий на ленточную библиотеку.
В случае первого варианта проблемой становится чрезвычайно высокая стоимость дискового пространства для хранения резервных копий — так или иначе, нужно достаточно продолжительное время хранить несколько копий данных. Для минимизации рисков либо для соответствия нормативным требованиям компания или организация вынуждена хранить несколько резервных копий, что приводит к необходимости резервирования в разы большего объема дискового пространства по сравнению с объемом продуктивной копии данных. В условиях Больших Данных этот подход экономически необоснован. Однако можно обратиться к специализированным системам с богатым функционалом хранения данных. Но продуктивная база данных при классическом хранении по строкам, как правило, не может быть существенно сжата, и основной эффект будет получен только при последующем размещении дополнительных резервных копий данных. При этом каждый раз дедупликации будет эффективно подвергнута только неизменяемая часть данных, копия которых уже присутствует в системе хранения, а новые и измененные данные будут сжиматься неэффективно. В результате для резервного копирования будет необходим не меньший объем дискового пространства, чем объем продуктивных данных в исходном виде. В совокупности с высокой стоимостью устройств это может привести к тому, что стоимость системы хранения для резервных копий данных будет сопоставима либо выше стоимости продуктивной копии. Кроме того, специализация означает, что администраторам нужно очень хорошо понимать механизм работы систем и учитывать ограничения технологии, чтобы максимально полно использовать имеющийся функционал.
Второе решение по хранению резервных копий данных — ленточные библиотеки, однако и здесь есть свои ограничения, и прежде всего по скорости и сложности процедур резервного копирования, а также восстановления данных. Кроме того, как и в предыдущем случае, ленточные библиотеки накладывают ограничения на возможность активной работы с резервной копией данных.
Таким образом, оптимальным вариантом можно считать комбинацию ленточных и дисковых решений, что позволяет получить преимущества обоих при минимизации ограничений. Резервная копия данных располагается на дисковом массиве, откуда в дальнейшем может быть перенесена на ленточную библиотеку. При этом могут быть совмещены высокая производительность и простота оперативного восстановления дискового решения и низкая стоимость хранения ленточных накопителей, а также возможность их отчуждения и хранения вне ЦОД.
Но как же быть со стоимостью дискового пространства для оперативной резервной копии? В системе Exadata поддерживается гибридное поколоночное сжатие HCC на дисковых массивах, позволяющее иногда на порядок уменьшать размер резервной копии, что снижает стоимость хранения. Также в этой системе имеется возможность доступа к базе данных непосредственно из резервной копии без необходимости восстановления либо распаковки данных. Почему это важно? Для обеспечения надежного функционирования информационной системы требуется хранить как основные, так и резервные копии данных, количество и время хранения которых, как правило, фиксировано и не может быть изменено без повышения уровня риска для предприятия, но это еще не все копии. Большинство компаний использует дополнительные копии для тестирования и разработки, а также задач, связанных с аналитикой, — все эти задачи могут создать неприемлемо высокую дополнительную нагрузку на основную копию данных либо всю систему хранения, поэтому для них используются дополнительные внешние хранилища. Этих дополнительных инвестиций можно избежать, если в компании уже есть оперативная резервная копия данных на внешней системе хранения.
Для создания оперативной резервной копии необходимо на уровне системы хранения сделать снимок резервной копии без изменений, после чего можно начинать с ней работать без необходимости распаковки и копирования данных благодаря, например, технологии HCC. Создание снимков, как правило, существенно дополнительно нагружает систему хранения, однако в Oracle Sun ZFS Storage Appliance имеется специальный алгоритм, позволяющий этого избежать. Таким образом, оптимальная инфраструктура хранения баз данных Oracle может выглядеть следующим образом. Основная копия данных расположена, например, на системе Exadata с гибридным поколоночным сжатием для уменьшения объема. Система Oracle Sun ZFS Storage Appliance подключается к Exadata по интерфейсу Infiniband, что в совокупности с тем фактом, что данные передаются в сжатом виде, позволяет уменьшить окно резервного копирования. После того как данные будут сохранены на Oracle Sun ZFS Storage Appliance, последующие резервные копии могут быть инкрементальными и средствами Oracle RMAN объединяться с уже существующей полной резервной копией, тем самым оптимизируя и ускоряя процедуры резервного копирования и восстановления. После этого система Exadata исключается из процесса, на нее нет дополнительной нагрузки, и данные с системы хранения могут быть перенесены на ленточный накопитель либо, благодаря технологии моментальных снимков, параллельно с этим открыты для тестирования, разработки и выполнения аналитических запросов без создания дополнительных копий. Кроме того, на системе Oracle Sun ZFS Storage Appliance параллельно могут быть размещены, например, виртуальные машины и файловые данные, которые будут сжаты алгоритмами компрессии общего назначения и с применением технологии блочной дедупликации.
***
Комплексная архитектура хранения позволяет минимизировать число избыточных копий данных, сократить затраты на приобретение и обслуживание дополнительных систем хранения, а также повысить производительность выполнения тестовых либо аналитических задач.
Владимир Гречушкин (pr-team_ru@oracle.com) — менеджер по продажам систем хранения данных, Oracle Hardware (Москва).
