У папярэдніх пастах мы дзяліліся інструкцыямі па наладзе и на базе 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 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.
На сёньня ўсё. Задавайце пытанні ў каментарах.
Крыніца: habr.com