HPE StoreOnce Часть 3: Базовые возможности Catalyst

Ключевой особенностью Catalyst является возможность дедупликации данных до передачи их на сам массив. Данную возможность должно поддерживать само ПО для резервного копирования (и наиболее популярные продукты его поддерживают) и уметь общаться со StoreOnce по данному API.

Логически это общение довольно просто: поток данных разбивается на чанки размером от 2 до 10КБ. Затем для каждого чанка вычисляется 160 битный хэш, хэши собираются в список и отправляются массиву. Один список хэшей равен примерно 10МБ пользовательских данных. Массив в своей базе хэшей проверяет полученный список на уникальность хэшей в нём. В случае, если хэш чанка является уникальным, передаётся сам чанк данных и StoreOnce записывает его хэш в свою базу. Если же данный хэш найден в базе, передачи данных не осуществляется, а лишь ставится пометка, что данный чанк уже есть на массиве и указывается ссылка на него. Это позволяет передавать на массив только уникальные данные, осуществляя таким образом дедупликацию на стороне сервера резервного копирования.

Конечно на свежеустановленном массиве мы не увидим эффективности данной технологии, но со временем, когда у нас накопится некий объём данных, это позволит экономить как объём, так и увеличить скорость резервного копирования. При чём, если у вас несколько систем StoreOnce и между ними выполняется репликация, ПО для резервного копирования получает информацию обо всех копиях данных, и в случае недоступности основной системы, может производить восстановления с резервного StoreOnce.
Если же вы используете ПО без поддержки Catalyst это совсем не значит, что вы теряете возможность дедупликации данных. Классическая дедупликация на стороне СХД здесь так же присутствует.
Catalyst даёт возможность подключатся к StoreOnce несколькими медиа-серверам (прокси или гейтвеям — именование зависит от ПО для резервного копирования, которое вы используете), получая единое хранилище для всех серверов и для них для всех будет доступна дедупликация.
Как я уже говорил в предыдущей части — в 4-й версии сильно упростили интерфейс управления, да и настроек не очень много в целом.

Политики передачи данных:
Низкая пропускная способность — основной режим работы через Catalyst, когда дедупликация выполняется на сервере резервного копирования и передаются на СХД только уникальные данные.
Высокая пропускная способность — передаются все данные, а дедупликация выполняется уже на самой СХД.
При такой конфигурации, как на скриншоте — сервер резервного копирования должен самостоятельно выбрать в каком режиме он будет работать с массивом. Если же вы хотите принудительно выставить один из режимов, то его необходимо одинаково указать для обоих режимов. Но, на сколько мне известно, только DataProtector умеет работать в такой конфигурации, поэтому рекомендуется всё-таки самостоятельно указывать режим для обеих политик.
Теперь же поговорим о недостатках. Естественно, этого нет в курсах, но т.к. я уже довольно порядочное время имею дело как с продуктами резервного копирования, так и самим StoreOnce — не могу не поделиться своими мыслями.
Во-первых — скорость восстановления. Проблема дедупликации в том, что наши файлы резервных копий благодаря этому, расположены на массиве «не равномерно» и когда мы считываем какой-то из бекапов, получаем вместо последовательного чтения рандомное. Естественно это не сильно положительно сказывается на скорости и как следствие — времени восстановления.
Во-вторых — множество ограничений. Если вы читаете мой блог уже какое то время, то вы знаете, что я активно использую Veeam. В частности, при работе Veeam со StoreOnce есть следующий ряд ограничений:

  • Когда вы используете HPE StoreOnce в качестве репозитория, Veeam Backup & Replication работает в Use per-VM backup files, что негативно сказывается на дедупликации, т.к. каждая ВМ бекапится в отдельный файл.
  • При работе с HPE StoreOnce не поддерживается reverse incremental и forever forward бекапы.
  • Не может быть источником или целью задания копирования (copy job).
  • Не может быть таргетом для агентского бекапа (через Catalyst). В качестве обходного решения рекомендуется создавать репозитой с HPE StoreOnce по CIFS.

Уверен, что, если внимательно прочитать документацию к другим продуктам резервного копирования — там так же найдутся свои ограничения по использованию протокола Catalyst.

 

Один ответ к «HPE StoreOnce Часть 3: Базовые возможности Catalyst»

  1. Уведомление: HPE StoreOnce — KorP`s blog

Добавить комментарий