В предыдущих постах мы делились инструкциями по настройке резервного копирования и репликации на базе Veeam. Сегодня мы хотим рассказать про резервное копирование средствами Commvault. Инструкций не будет, зато расскажем, что и как уже бэкапят наши клиенты.
СХД системы резервного копирования на базе Commvault в дата-центре OST-2.
Commvault – это платформа для резервного копирования приложений, баз данных, файловых систем, виртуальных машин и физических серверов. Исходные данные при этом могут быть на любой площадке: у нас – на стороне клиента, в другом коммерческом дата-центре или облаке.
Клиент устанавливает на объекты резервного копирования агент – iData Agent – и настраивает его в соответствии с требуемыми политиками бэкапа. iData Agent собирает необходимые данные, сжимает, дедуплицирует, шифрует и передает их в систему резервного копирования DataLine.
Proxy-серверы обеспечивают связность клиентской сети и нашей сети, изоляцию каналов, по которым передаются данные.
На стороне DataLine данные от iData Agent принимает Media Agent Server и отправляет на хранение на СХД, ленточные библиотеки и пр. Всем этим управляет CommServe. В нашей конфигурации основной управляющий сервер находится на площадке OST, резервный – на площадке NORD.
По умолчанию данные клиента складываются на одну площадку, но можно организовать резервное копирование сразу на две локации или настроить расписание по переносу бэкапов на вторую площадку. Эта опция называется “дополнительная копия данных” (auxiliary copy). Например, все полные бэкапы в конце месяца будут автоматически дублироваться или переезжать на вторую площадку.
Схема работы системы резервного копирования Commvault.
Система резервного копирования работает преимущественно на виртуализации VMware: на виртуальных машинах развернуты серверы CommServe, Media Agent и Proxy-серверы. Если клиент использует наше оборудование, то бэкапы размещаются на СХД Huawei OceanStor 5500 V3. Для резервного копирования клиентских СХД, хранения бэкапов на ленточных библиотеках используются отдельные Media Agent на физических серверах.
Из нашей практики клиенты, которые для резервного копирования выбирают Commvault, обращают внимание на следующие моменты.
Консоль. Клиенты хотят управлять резервным копированием самостоятельно. В консоли Commvault доступны все основные операции:
Дедупликация. Дедупликация позволяет находить и удалять повторяющиеся блоки данных в процессе резервного копирования. Таким образом она помогает экономить место на СХД и уменьшает объем передаваемых данных, снижая требования к скорости канала. Без дедупликации, резервные копии занимали бы объем в два-три раза превышающий объем исходных данных.
В случае с Commvault дедупликацию можно настроить на стороне клиента или на стороне Media Agent. В первом случае неуникальные блоки данных даже не будут передаваться на Media Agent Server. Во втором повторяющийся блок отбрасывается и не записывается на СХД.
Такая блочная дедупликация основана на хэш-функциях. Каждому блоку присваивается хэш, который сохраняется в хэш-таблице, своего рода базе данных (Deduplication Database, DDB). При передаче данных хэш “пробивается” по этой базе. Если такой хэш уже есть в базе, то блок помечается как неуникальный и не передается на Media Agent Server (в первом случае) или не записывается на систему хранения данных (во втором).
Благодаря дедупликации нам удается экономить до 78% места в системе хранения. Сейчас на СХД хранится 166,4 ТБ. Без дедупликации нам пришлось бы хранить 744 ТБ.
Возможность разграничивать права. В Commvault есть возможность устанавливать разные уровни доступа к управлению резервным копированием. Так называемые “роли” определяют, какие действия будут разрешены пользователю по отношению к объектам резервного копирования. Например, разработчики смогут только восстанавливать сервер с базой данных в определенное место, а администратор сможет запускать внеочередное резервное копирование для этого же сервера, добавлять новых пользователей.
Шифрование. Шифровать данные во время резервного копирования через Commvault можно следующими способами:
Доступные агоритмы шифрований: Blowfish, GOST, Serpent, Twofish, 3-DES, AES (рекомендуемый Commvault).
На середину декабря с помощью Commvault у нас бэкапятся 27 клиентов. Большую часть из них составляют ритейлеры и финансовые организации. Общий объем исходных данных копии занимает 65 ТБ.
В день выполняется около 4400 заданий. Ниже статистика по выполненным заданиям за последние 16 дней.
Больше всего через Commvault бэкапят Windows File System, SQL Server и базы данных Exchange.
А теперь обещанные кейсы. Хоть и обезличенные (NDA передает привет :)), но они дают представление, для чего и как клиенты используют бэкап на базе Commvault. Ниже представлены кейсы по клиентам, которые используют единую систему резервного копирования, т. е. общие ПО, Media Agent Servers и системы хранения.
Заказчик. Российская торгово-производственная компания кондитерского рынка с распределенной сетью филиалов по России.
Задача.Организация резервного копирования для баз данных Microsoft SQL, файловых серверов, серверов приложений, почтовые ящики Exchange Online.
Исходные данные располагаются в офисах по всей России (более 10 городов). Бэкапить нужно на площадку DataLine с последующим восстановлением данных в любой из офисов компании.
При этом клиент хотел полного самостоятельного управления с разграничением доступа.
Глубина хранения – год. Для Exchange Online – 3 месяца для оперативных копий и год для архивов.
Решение. Для баз данных была настроена дополнительная копия на вторую площадку: последний полный бэкап месяца переносится на другую площадку и хранится там год.
Качество каналов из удаленных офисов клиента не всегда позволяло делать бэкап и восстановление в оптимальные сроки. Чтобы уменьшить объем передаваемого трафика, на стороне клиента была настроена дедупликация. Благодаря ей время полного резервного копирования стало приемлемым с учетом удаленности офисов. Например, полный бэкап базы данных объемом 131 ГБ из Санкт-Петербурга делается за 16 минут. Из Екатеринбурга база данных 340 ГБ бэкапится 1 час 45 минут.
С помощью ролей клиент настроил для своих разработчиков разные разрешения: только на резервное копирование или восстановление.
Заказчик. Российская сеть магазинов детских товаров.
Задача. Организация резервного копирования для:
высоконагруженного кластера MS SQL на базе 4 физических серверов;
виртуальных машин с сайтом, серверами приложений, 1С, Exchange и файловыми серверами.
Вся указанная инфраструктура клиента разнесена между площадками OST и NORD.
RPO для SQL-серверов – 30 минут, для остальных – 1 сутки.
Глубина хранения – от 2 недель до 30 дней в зависимости от типа данных.
Решение. Выбрали сочетание решений на базе Veeam и Commvault. Для файлового резервного копирования из нашего облака используется Veeam. Сервера баз данных, Active Directory, почтовые и физические сервера бэкапятся через Commvault.
Для достижения высокой скорости резервного копирования клиент выделил на физических серверах с MS SQL отдельный сетевой адаптер под задачи бэкапа. Полный бэкап базы данных объемом 3,4 ТБ занимает 2 часа 20 минут, а полное восстановление – 5 часов 5 минут.
У клиента был большой объем исходных данных (почти 18 ТБ). Если складывать данные на ленточную библиотеку, как клиент это делал ранее, то потребовалось бы несколько десятков картриджей. Это усложнило бы менеджмент всей системы резервного копирования клиента. Поэтому в итоговой реализации ленточная библиотека была заменена на СХД.
Заказчик. Сеть супермаркетов в СНГ
Задача. Заказчик хотел организовать резервное копирование и восстановление SAP-систем, размещавшихся в нашем облаке. Для баз данных SAP HANA RPO=15 минут, для виртуальных машин с серверами приложений RPO=24 часа. Глубина хранения – 30 дней. В случае аварии RTO=1 час, для восстановления копии по запросу RTO=4 часа.
Решение. Для БД HANA было настроено резервное копирование DATA-файлов и Log-файлов c заданной периодичностью. Log-файлы архивировались каждые 15 минут или при достижении определенного размера.
Чтобы уменьшить время восстановления БД, мы настроили двухуровневое хранение бэкапов на базе СХД и ленточной библиотеки. На диски складываются оперативные копии с возможностью восстановления на любой момент в течение недели. Когда бэкап становится старше 1 недели, он перемещается в архив, на ленточную библиотеку, где хранится еще 30 дней.
Полный бэкап одной из баз данных объемом 181 ГБ делается за 1 час 54 минуты.
При настройке резервного копирования использовался backint интерфейс SAP, позволяющий интегрировать системы резервного копирования сторонних разработчиков с SAP HANA Studio. Поэтому резервным копированием можно управлять напрямую из консоли SAP. Это упрощает жизнь SAP-администраторам, которым не нужно привыкать к новому интерфейсу.
Управление резервным копированием также доступно клиенту через стандартную клиентскую консоль Commvault.
На сегодня все. Задавайте вопросы в комментариях.
СХД системы резервного копирования на базе Commvault в дата-центре OST-2.
Как это работает?
Commvault – это платформа для резервного копирования приложений, баз данных, файловых систем, виртуальных машин и физических серверов. Исходные данные при этом могут быть на любой площадке: у нас – на стороне клиента, в другом коммерческом дата-центре или облаке.
Клиент устанавливает на объекты резервного копирования агент – iData Agent – и настраивает его в соответствии с требуемыми политиками бэкапа. iData Agent собирает необходимые данные, сжимает, дедуплицирует, шифрует и передает их в систему резервного копирования DataLine.
Proxy-серверы обеспечивают связность клиентской сети и нашей сети, изоляцию каналов, по которым передаются данные.
На стороне DataLine данные от iData Agent принимает Media Agent Server и отправляет на хранение на СХД, ленточные библиотеки и пр. Всем этим управляет CommServe. В нашей конфигурации основной управляющий сервер находится на площадке OST, резервный – на площадке NORD.
По умолчанию данные клиента складываются на одну площадку, но можно организовать резервное копирование сразу на две локации или настроить расписание по переносу бэкапов на вторую площадку. Эта опция называется “дополнительная копия данных” (auxiliary copy). Например, все полные бэкапы в конце месяца будут автоматически дублироваться или переезжать на вторую площадку.
Схема работы системы резервного копирования Commvault.
Система резервного копирования работает преимущественно на виртуализации VMware: на виртуальных машинах развернуты серверы CommServe, Media Agent и Proxy-серверы. Если клиент использует наше оборудование, то бэкапы размещаются на СХД Huawei OceanStor 5500 V3. Для резервного копирования клиентских СХД, хранения бэкапов на ленточных библиотеках используются отдельные Media Agent на физических серверах.
Что важно клиентам?
Из нашей практики клиенты, которые для резервного копирования выбирают Commvault, обращают внимание на следующие моменты.
Консоль. Клиенты хотят управлять резервным копированием самостоятельно. В консоли Commvault доступны все основные операции:
- добавление и удаление серверов на резервное копирование;
- настройка iData Agent;
- создание и ручной запуск заданий;
- самостоятельное восстановление резервных копий;
- настройка оповещений о статусе задач резервного копирования;
- разграничение доступа к консоли в зависимости от роли и группы пользователей.
Дедупликация. Дедупликация позволяет находить и удалять повторяющиеся блоки данных в процессе резервного копирования. Таким образом она помогает экономить место на СХД и уменьшает объем передаваемых данных, снижая требования к скорости канала. Без дедупликации, резервные копии занимали бы объем в два-три раза превышающий объем исходных данных.
В случае с Commvault дедупликацию можно настроить на стороне клиента или на стороне Media Agent. В первом случае неуникальные блоки данных даже не будут передаваться на Media Agent Server. Во втором повторяющийся блок отбрасывается и не записывается на СХД.
Такая блочная дедупликация основана на хэш-функциях. Каждому блоку присваивается хэш, который сохраняется в хэш-таблице, своего рода базе данных (Deduplication Database, DDB). При передаче данных хэш “пробивается” по этой базе. Если такой хэш уже есть в базе, то блок помечается как неуникальный и не передается на Media Agent Server (в первом случае) или не записывается на систему хранения данных (во втором).
Благодаря дедупликации нам удается экономить до 78% места в системе хранения. Сейчас на СХД хранится 166,4 ТБ. Без дедупликации нам пришлось бы хранить 744 ТБ.
Возможность разграничивать права. В Commvault есть возможность устанавливать разные уровни доступа к управлению резервным копированием. Так называемые “роли” определяют, какие действия будут разрешены пользователю по отношению к объектам резервного копирования. Например, разработчики смогут только восстанавливать сервер с базой данных в определенное место, а администратор сможет запускать внеочередное резервное копирование для этого же сервера, добавлять новых пользователей.
Шифрование. Шифровать данные во время резервного копирования через Commvault можно следующими способами:
- на стороне клиентского агента: данные в этом случае будут передаваться в систему резервного копирования уже в зашифрованном виде;
- на стороне Media Agent;
- на уровне канала: данные шифруются на стороне клиентского агента и расшифровываются на Media Agent Server.
Доступные агоритмы шифрований: Blowfish, GOST, Serpent, Twofish, 3-DES, AES (рекомендуемый Commvault).
Немного статистики
На середину декабря с помощью Commvault у нас бэкапятся 27 клиентов. Большую часть из них составляют ритейлеры и финансовые организации. Общий объем исходных данных копии занимает 65 ТБ.
В день выполняется около 4400 заданий. Ниже статистика по выполненным заданиям за последние 16 дней.
Больше всего через Commvault бэкапят Windows File System, SQL Server и базы данных Exchange.
А теперь обещанные кейсы. Хоть и обезличенные (NDA передает привет :)), но они дают представление, для чего и как клиенты используют бэкап на базе Commvault. Ниже представлены кейсы по клиентам, которые используют единую систему резервного копирования, т. е. общие ПО, Media Agent Servers и системы хранения.
Кейс 1
Заказчик. Российская торгово-производственная компания кондитерского рынка с распределенной сетью филиалов по России.
Задача.Организация резервного копирования для баз данных Microsoft SQL, файловых серверов, серверов приложений, почтовые ящики Exchange Online.
Исходные данные располагаются в офисах по всей России (более 10 городов). Бэкапить нужно на площадку DataLine с последующим восстановлением данных в любой из офисов компании.
При этом клиент хотел полного самостоятельного управления с разграничением доступа.
Глубина хранения – год. Для Exchange Online – 3 месяца для оперативных копий и год для архивов.
Решение. Для баз данных была настроена дополнительная копия на вторую площадку: последний полный бэкап месяца переносится на другую площадку и хранится там год.
Качество каналов из удаленных офисов клиента не всегда позволяло делать бэкап и восстановление в оптимальные сроки. Чтобы уменьшить объем передаваемого трафика, на стороне клиента была настроена дедупликация. Благодаря ей время полного резервного копирования стало приемлемым с учетом удаленности офисов. Например, полный бэкап базы данных объемом 131 ГБ из Санкт-Петербурга делается за 16 минут. Из Екатеринбурга база данных 340 ГБ бэкапится 1 час 45 минут.
С помощью ролей клиент настроил для своих разработчиков разные разрешения: только на резервное копирование или восстановление.
Кейс 2
Заказчик. Российская сеть магазинов детских товаров.
Задача. Организация резервного копирования для:
высоконагруженного кластера MS SQL на базе 4 физических серверов;
виртуальных машин с сайтом, серверами приложений, 1С, Exchange и файловыми серверами.
Вся указанная инфраструктура клиента разнесена между площадками OST и NORD.
RPO для SQL-серверов – 30 минут, для остальных – 1 сутки.
Глубина хранения – от 2 недель до 30 дней в зависимости от типа данных.
Решение. Выбрали сочетание решений на базе Veeam и Commvault. Для файлового резервного копирования из нашего облака используется Veeam. Сервера баз данных, Active Directory, почтовые и физические сервера бэкапятся через Commvault.
Для достижения высокой скорости резервного копирования клиент выделил на физических серверах с MS SQL отдельный сетевой адаптер под задачи бэкапа. Полный бэкап базы данных объемом 3,4 ТБ занимает 2 часа 20 минут, а полное восстановление – 5 часов 5 минут.
У клиента был большой объем исходных данных (почти 18 ТБ). Если складывать данные на ленточную библиотеку, как клиент это делал ранее, то потребовалось бы несколько десятков картриджей. Это усложнило бы менеджмент всей системы резервного копирования клиента. Поэтому в итоговой реализации ленточная библиотека была заменена на СХД.
Кейс 3
Заказчик. Сеть супермаркетов в СНГ
Задача. Заказчик хотел организовать резервное копирование и восстановление SAP-систем, размещавшихся в нашем облаке. Для баз данных SAP HANA RPO=15 минут, для виртуальных машин с серверами приложений RPO=24 часа. Глубина хранения – 30 дней. В случае аварии RTO=1 час, для восстановления копии по запросу RTO=4 часа.
Решение. Для БД HANA было настроено резервное копирование DATA-файлов и Log-файлов c заданной периодичностью. Log-файлы архивировались каждые 15 минут или при достижении определенного размера.
Чтобы уменьшить время восстановления БД, мы настроили двухуровневое хранение бэкапов на базе СХД и ленточной библиотеки. На диски складываются оперативные копии с возможностью восстановления на любой момент в течение недели. Когда бэкап становится старше 1 недели, он перемещается в архив, на ленточную библиотеку, где хранится еще 30 дней.
Полный бэкап одной из баз данных объемом 181 ГБ делается за 1 час 54 минуты.
При настройке резервного копирования использовался backint интерфейс SAP, позволяющий интегрировать системы резервного копирования сторонних разработчиков с SAP HANA Studio. Поэтому резервным копированием можно управлять напрямую из консоли SAP. Это упрощает жизнь SAP-администраторам, которым не нужно привыкать к новому интерфейсу.
Управление резервным копированием также доступно клиенту через стандартную клиентскую консоль Commvault.
На сегодня все. Задавайте вопросы в комментариях.
Поделиться с друзьями
Комментарии (9)
navion
22.12.2016 23:38А можно поподробнее про RTO=1 час? Делались какие-то специальные настройки с сайзингом пулов и приоретизация или просто база маленькая?
dataline
23.12.2016 10:43RTO=1 час обеспечивается средствами резервного сервера для SAP HANA. В случае аварии на основном сервере данные доступны на резервном.
В случае обычного запроса на полное восстановление из бэкапа у нас есть 4 часа.
База 256 GB.
medvedevia
23.12.2016 10:10Интуитивно-понятный интерфейс — вот что я никогда бы не сказал про эту программу))
FlashHaos
31.12.2016 00:08Почему СХД, а не дисковая библиотека того или иного производителя, с онлайн-дедупом?
Используется ли прямое подключение клиентов к устройствам РК (по SAN), или до медиасерверов идёт по IP?
181ГБ за 2 часа — это какая-то невероятная скорость. Я понимаю, что это shared решение, но как-то совсем печально.
krids
27 MB/s? Что- то совсем не быстро. Дедупликация где выполнялась? На HANA-хосте или медиа-агенте?
Хм… на LTO-6 картридже с компрессией вполне себе лежат 4 бекапа 1.5TB базы.
Не совсем в тему вопрос: клиент хостит HANA'у на выделенных физ. машинах или на виртуалках?
Пост интересный. Спасибо.
dataline
Это время включает в себя дедупликацию, сжатие и собственно передачу данных. Для shared системы резервного копирования — это приемлемая скорость. На выделенных решениях, например, кейс 2, скорость будет выше – до 3 Gb/s. Дедупликация на стороне клиента.
Да, возможно, в вашем случае этот вариант приемлем. В нашем же кейсе клиент использовал ленты LTO-5 в качестве основной системы хранения. Наличие сжатия никак не отменяло большое количество картриджей. Более того, степень сжатия не гарантируется и варьируется от случая к случаю, поэтому и остановились на СХД.
HANA работает на виртуальных машинах.
krids
Ясно. Спасибо.
А ваше облако каким-то образом сертифицировано SAP-ом под HANA (спрашиваю потому что обнаружить вас в списке SAP HANA Certified IaaS Platforms не удалось)?
dataline
У клиента развернут частный кластер на базе оборудования, входящем в лист сертификации SAP для размещения HANA (TDI).
krids
Тогда понятно :)