У попередніх постах ми ділилися інструкціями з налаштування и на базі 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 доступні всі основні операції:
- додавання та видалення серверів на резервне копіювання;
- налаштування iData Agent;
- створення та ручний запуск завдань;
- самостійне відновлення резервних копій;
- налаштування оповіщень про статус завдань резервного копіювання;
- розмежування доступу до консолі залежно від ролі та групи користувачів.
Дедуплікація. Дедуплікація дозволяє знаходити і видаляти блоки даних, що повторюються, в процесі резервного копіювання. Таким чином вона допомагає економити місце на СГД і зменшує обсяг даних, що передаються, знижуючи вимоги до швидкості каналу. Без дедуплікації, резервні копії займали б обсяг у два-три рази, що перевищує обсяг вихідних даних.
У випадку з Commvault дедуплікацію можна настроїти на стороні клієнта або Media 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-файлів з заданою періодичністю. Log-файли архівувалися кожні 15 хвилин або при досягненні певного розміру.
Щоб зменшити час відновлення БД, ми налаштували дворівневе зберігання бекапів на базі СГД та стрічкової бібліотеки. На диски складаються оперативні копії з можливістю відновлення будь-якої миті протягом тижня. Коли бекап стає старше 1 тижня, він переміщається до архіву, на стрічкову бібліотеку, де зберігається ще 30 днів.
Повний бекап однієї з баз даних обсягом 181 ГБ виробляється за 1 годину 54 хвилини.
При налаштуванні резервного копіювання використовувався backint інтерфейс SAP, що дозволяє інтегрувати системи резервного копіювання сторонніх розробників із SAP HANA Studio. Тому резервне копіювання можна керувати безпосередньо з консолі SAP. Це полегшує життя SAP-адміністраторам, яким не потрібно звикати до нового інтерфейсу.
Управління резервним копіюванням також доступне клієнту через стандартну консоль клієнта Commvault.
На сьогодні все. Ставте запитання в коментарях.
Джерело: habr.com