В предишните постове споделихме инструкции за настройка и на база 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.
Налични алгоритми за криптиране: Blowfish, GOST, Serpent, Twofish, 3-DES, AES (препоръчителен Commvault).
Няколко статистики
Към средата на декември с Commvault архивираме 27 клиенти. По-голямата част от тях са търговци на дребно и финансови организации. Общият обем на оригиналните данни за копието е 65 TB.
На ден се извършват около 4400 задачи. По-долу е статистиката за завършените задачи през последните 16 дни.
Най-много чрез Commvault архивират Windows File System, SQL Server и бази данни Exchange.
А сега обещаните случаи. Въпреки че са анонимизирани (NDA предава поздрави :)), те дават представа за това как и за какво клиентите използват архивирането на базата на Commvault. По-долу са представени случаи на клиенти, които използват единна система за архивиране, т.е. общи софтуер, Media Agent Servers и системи за съхранение.
Случай 1
Клиент. Руска търговско-производствена компания от сладкарския сектор с разпределена мрежа от филиали в Русия.
Задача.Организиране на архивиране за бази данни Microsoft SQL, файлови сървъри, сървъри на приложения, пощенски кутии Exchange Online.
Оригиналните данни са разположени в офиси из цяла Русия (повече от 10 града). Архивирането трябва да се извършва на DataLine с последващо възстановяване на данни в който и да е офис на компанията.
При това клиентът искаше пълно независимо управление с ограничаване на достъпа.
Дълбочина на съхранение – 1 година. За Exchange Online – 3 месеца за оперативни копия и 1 година за архиви.
Решение. За бази данни беше настроена допълнителна копия на второ място: последният пълен архив на месеца се прехвърля на друго място и се съхранява там 1 година.
Качеството на каналите от отдалечените офиси на клиента не винаги позволяваше архивирането и възстановяването в оптимални срокове. За да се намали обемът на пренесения трафик, на страната на клиента беше настроена дедупликация. Благодарение на нея времето за пълно архивиране стана приемливо, като се взема предвид отдалечеността на офисите. Например, пълно архивиране на база данни с обем 131 GB от Санкт-Петербург се извършва за 16 минути. От Екатеринбург база данни с 340 GB се архивира за 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 TB отнема 2 часа и 20 минути, а пълното възстановяване – 5 часа и 5 минути.
Клиентът имаше голям обем на изходни данни (почти 18 TB). Ако данните се съхраняват на лента, както клиентът правеше по-рано, ще са необходими десетки касети. Това би усложнило управлението на цялата система за резервно копиране на клиента. Затова в окончателната реализация касетната библиотека беше заменена с СХД.
Случай 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
