Як влаштовані бекапи замовників у нашому дата-центрі TierIII



Найпростіше — наше S3-сховище. У цьому випадку ми надаємо тільки простір, без якоїсь логіки та організації копіювання. Дешево, просто, надійно, як удар кийком у темряві. В S3 вміють копіювати більшість продуктів бекапу — Veritas Internet/Backup Exec, CommVault, Veeam, EMC Networker та ін. Таке рішення розгортається за 2 години.

Другий підхід — повноцінна інфраструктура резервного копіювання. Ми даємо замовнику фактично в оренду частина програмно-апаратного комплексу. І в цьому випадку замовник отримує не просто хранилку, а сервіс резервного копіювання цілком, включаючи програмну організацію логіки копіювання. Наприклад, якщо замовник розміщується в дата-центрі на Волочаєвський і користується послугою, то комплекс Avamar збирає бекапи з його інфраструктури і робить копію в цьому ж Цоді, так і копію на інший майданчик при необхідності. Крім цього, в системі є внутрішні засоби захисту самого Avamar — зліпок системи знімається два рази на добу, дедуплицируется, стискається.

Все, звичайно, чудово, але з об'єктивних причин (криза все встигли відчути) ми стали шукати більш бюджетні, але при цьому функціональні варіанти.

Почнемо з Авамара, раз вже згадали

Для вирішення завдань збереження резервних копій за межами локальної інфраструктури ми встановили ПАК EMC Avamar. Класична Схема: на скопійовані машини встановлюється клієнтське додаток, воно інтегрується з операційною системою та програмним забезпеченням, збирає дані, дедуплицирует їх і відправляє в наш ЦОД. Копіювання завжди інкрементні: спочатку система робить повну копію даних, а потім тільки змінні блоки (зазвичай 1-3% від загального обсягу). Це дозволяє значно знизити навантаження на канал і зменшити вікно резервного копіювання. З точки зору доступу — це синтетичні повні резервні копії.

Плюси:
  • швидке копіювання за рахунок дедуплікаціі і стиснення;
  • хороша ціна;
  • можливість відновлення в інфраструктурі нашого дата-центру на віртуальні машини;
  • гарантія відновлення: це масив на RAIN-архітектурі з захистами від виходу з ладу дисків/полиць і внутрішніми перевірками консистентности даних. Це більш надійний носій для зберігання інформації, ніж звичайний стрічковий картридж — не в останню чергу тому він був обраний нами як основна хмарне сховище;
  • витрати на бекап зростають у міру зростання вимог, а не стрибками з капітальними витратами;
  • мінімум занепокоєння і робіт по підтримці з боку замовника. Ми спільно з замовником здійснюємо стартову налаштування, а також моніторимо статус роботи системи (це безкоштовно);
  • підходить для тих, хто не може купувати і залізо від іноземних постачальників.



Цоді «Компресор» розгорнута інфраструктура, що включає ПАК Avamar та інтегрована з vcloud (одне з плечей хмарної інфраструктури КРОК) і хмарою КРОК (хмарне рішення на основі KVM).

Мінуси:
  • резервне копіювання і відновлення на локальній майданчику повністю залежить від якості інтернет-каналу.


Замовникам часто буває потрібно щось маленьке в бекапе, наприклад, окреме віддалене вчора лист, якийсь конкретний файл або щось ще. Досить нерозумно розгортати весь образ з-за файлу «1.txt», який користувач випадково перезаписав на своєму робочому столі. ПАК Авамар надає адміністраторам ЗА зручну консоль і хороший GUI для роботи з файлами додатків і користувачів. Вони самі можуть знаходити і відновлювати дані, не смикаючи адміна резервного копіювання. Природно, права доступу розмежовані.

Дешево і сердито

Оцінюючи різні варіанти реалізації, ми поступово прийшли до ще одного рішення — коли в інфраструктуру замовника віддаємо готове бекапное рішення під ключ:



CrocBackApp — це сервер з великою дискової ємністю і можливістю підключення зовнішніх дискових полиць, на який встановлено CommVault, який ми OEM'їм. За бажанням замовника сервери можна кластеризовать в одному шасі, та й взагалі побудувати майже будь-яке архітектурне рішення під потреби замовника.

По мірі тестування з'ясувалося ще одна важлива перевага такого рішення: простота налаштування та інтеграції в корпоративну середу. Тобто замовник бере залізо з нашим встановленим CrocBackApp, просто ставить до себе на майданчик, запускає, встановлює з допомогою візарда клієнтів на захищаються машини — і воно працює.

Плюс ми добиваємося смачних знижок за рахунок обсягів закупівлі заліза і якщо пробувати зібрати або придбати у великих вендорів таке рішення самостійно, вийде дорожче.

Нарівні з завданням зберігання резервних копій на віддаленій майданчику ще одна часта завдання — організація не тільки резервних копій, але і гнучкої інфраструктури у віддаленому Цоді, яку в годину ікс можна оперативно підняти. І тут ми пропонуємо замовнику вже не «Backup-as-a-Service», а фактично «Disaster Recovery-as-a-Service». Привабливість послуги в тому, що в штатному режимі замовник сплачує фактично тільки за зберігання і передачу даних у віддалений ЦОД, а в разі необхідності — починає споживати інфраструктуру цілком, причому може відновити її за лічені хвилини.

Подібну послугу — «Disaster Recovery-as-a-Service» — ми робимо різними способами:

  1. Є пряма реплікація між нашими хмарами і приватним хмарою або інфраструктурою замовника. Є хмари VMware, Hyper-V і KVM, куди дані можуть безпосередньо правильно засобами гіпервізора (наприклад vSphere Replication). Це самий простий і доступний метод реплікації.
  2. Відновлення інфраструктури з резервних копій у нашу хмарну інфраструктуру. Тут є вирішення різних виробників. Є Veeam Cloud Connect Replication, який дозволяє копіювати дані або бекапи по WAN-каналів в нашу інфраструктуру. В рамках нашого основного бекапного рішення — Avamar — ми можемо копіювати і відновлювати дані з різних середовищ — p2v, v2p, між різними хмарами (наприклад, Vmware в KVM, і навпаки).
  3. Третє рішення цікавіше:
Деякі наші замовники попросили повторити своє залізо (ОС) у наш хмара на наші віртуальні машини. Це якраз завдання «випав» офісу, коли клієнт може взяти і запустити щось зі свого бекапу прямо з хмари хвилин за 10. Реплікація з допомогою Zerto і Double-Take дозволяє віддзеркалювати дані операційної системи і додатків по IP з мінімальною затримкою. З технічного боку це виглядає як сервіс, який запускається всередині операційної системи або гіпервізора ESX і передає всі зміни до нам в хмару. З практичної сторони — це можливість для клієнта відновити працездатність програми в мінімально короткі терміни.



При подібному підході ми, крім технічного рішення, опрацьовуємо з замовниками і Disaster Recovery-плани на випадок аварійного відновлення. Так, щоб замовник сам міг протестувати або здійснити відновлення частини своїх машин або інфраструктуру

Практика

Рішення на базі Avamar вже років 5, а CrocBackApp — є пара прикладів. Якось до нас прийшла одна роздрібна мережа, у якої централізованого бекапу по всій інфраструктурі не було, а можливостей «маленького», розрахованого на окремі офіси, не вистачало. Залізо і скрізь було різне, а коли щось падало, починався цирк і зоопарк у спробах охопити все назад. Ні, це, в цілому, працювало, але кожен окремий випадок вимагав компетенцій сисадміна, має 8-річний досвід роботи з цим середовищем і точно знає, що на якомусь археологічному шарі лежить. Саме він замовляв у нас «кубики» CrocBackApp, щоб раз і назавжди позбутися від цих кошмарів в регіонах.
Потім прийшли урядові установи: у них дані не найбільші, але важливі. У них наші «кубики» просто встромляються в комутатори FC або Ethernet, і встановлюються клієнти на всі локальні машини. Далі потрібно тільки налаштувати розклад бекапів і план сховища.

У результаті утворилася дуже проста схема:
  • Якщо бізнес з великою кількістю офісів або ж, навпаки, SMB, і не хоче/не має можливості встановити окреме залізо локально — впроваджуємо резервне копіювання Avamar. Там досить низька вартість зберігання і нульові початкові витрати. Тобто OPEX маленький, а CAPEX дорівнює нулю.
  • Для тих, у кого є можливість розміщувати обладнання на своїх майданчиках, ми пропонуємо CrocBackApp. OPEX менше, ніж з Avamar, але є CAPEX.
  • для тих, у кого вже є своя бекапная інфраструктура, пропонуємо скористатися нашими S3 для організації віддаленого зберігання.


Посилання

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.