Архітектура систем резервного копіювання, архівування та відновлення

Ми регулярно робимо стріми з нашого навчального центру. І, як показала практика, найбільш цікавим виявився стрім по адмініструванню EMC Data Domain. На початку курсу інструктор Кузьма Пашков зробив значний огляд про види дедуплікаціі, архітектурі систем копіювання і відновлення, по суті виклав університетський курс з архітектури таких систем на прикладі продуктів ЕМС, зробив огляд продуктів ЕМС, детально зупинився на Data Domain, а також зробив огляд курсу з адміністрування Data Domain. Чому Data Domain такий дорогий? Чому це не СГД? Що потрібно знати про проектування/пуско-наладці/налаштування/техдокументації цих систем? На що звертати увагу? — на ці та інші питання інструктор відповів вичерпно.



Під катом грандіозна розшифровка і відеозапис частини курсу.

Сім'я технологій і продуктів Backup Recovery Solutions

Мені, як інженеру, не соромно говорити про те, що цей продукт хороший, так як з усіх перерахованих аналогів — Data Domain з'явився на ринку перший, наскільки я пам'ятаю. За результатами випробувань і конкурсів вибирають саме це рішення. Застосувати до цих комплексів навіть найнижчої лінійки поняття «старий» можна дуже умовно, так як термін життя у цих рішень становить 5-7 років, що дуже немало.

Наш навчальний курс побудований в форматі тренінгу – 50% теорії і 50% практики, ясна річ, на початку я буду більше говорити. Сама лабораторія фізично знаходиться в США, там на кожного з вас, учасника тренінгу, варто повноцінний Data Domain.

Почнемо з потрібних вступних по системам зберігання ЕМС. Як я розумію, ви вже не перший раз стикаєтеся з продукцією компанії ЕМС, і пам'ятайте, що ЕМС, VMware, RSASecruity – це один конгломерат. Тому продукцію всіх цих корпорацій можна розглядати в рамках єдиної номенклатури, не в сенсі управління компаній, а в тому сенсі, що всі ці продукти інтегруються один з одним. У цьому досягнута дуже глибокий ступінь інтеграції. Ми будемо розглядати тільки продукти компанії ЕМС. Нас цікавить та її частина, яка називається Backup Recovery Solutions. Частина цих рішень вона, як би запозичена, за рахунок поглинених компаній. Наприклад, головний продукт, який називається Networker – повноцінне засіб резервного копіювання корпоративного класу, який б'ється зі своїми конкурентами на цьому ринку – звідки він? – з компанії Legata, яка з кінця 80-х років цей продукт розробляла, зараз це вже ЕМС.

Далі, той продукт, який ми з вами збираємося вивчити – Data Domain – була однойменна компанія, яка перша на ринку випустила подібний програмно-апаратний комплекс для зберігання резервних архівних копій, ЕМС її поглинула. Наступний – Avamar. Я спеціально перерахую головні продукти, тому що вони всі один з одним взаємопов'язані. Avamar – так раніше називалася компанія з Каліфорнії, яка знову ж випускала засоби резервного копіювання корпоративного класу з дедупликацией на джерелі, дуже специфічне рішення, яке революціонізував стратегію резервного копіювання, продукт раніше називався Axion, якщо я правильно пам'ятаю. І ще є Data Protection Adviser, щодо цього продукту я не пам'ятаю чи було це розробкою ЕМС, або це було поглинання компанії.

Насправді це не повний список, чому я перерахував всі ці продукти? Для того щоб сказати вам про те, що це все частини єдиного цілого – вже зараз, на дворі 2015 рік, ЕМС в прайс-листах, в роботі своїх присейлов, позиціонує всі ці продукти, як частини єдиного пакету продуктів в рамках Backup Recovery Solutions – єдиний продукт, який дозволяє уніфікувати захист будь-яких даних, які можуть зустрітися в будь-якій корпорації. Об'єднавши ці продукти вже протягом довгого часу, ЕМС навчило ці продукти дуже глибоко інтегруватися. Networker може працювати як сам, так і частина функцій делегувати Data Domain або Avamar, Avamar може безпосередньо інтегруватися з Data Domain без Networker, а можуть всі разом працювати в одній «зграї-лійці». Про Data Protection Advisor– взагалі окрема розмова.



У зв'язку з цим, на курсах з цих продуктів не можна про це не говорити, бо значна частина функціоналу зав'язана на ось цю інтеграцію. Якщо говорити про наш Data Domain, то в ньому значна частина функцій вже роками не змінюється – тому що там всі вже давно добре, ще до поглинання. Але після, більша частина удосконалень пов'язана з тим, що Data Domain повинен вміти «дружити» зі своїми «братами», щоб це стало єдиним цілим. Якщо розглядати кожен продукт окремо – це набір функцій, або послуг. Але коли ці продукти інтегруються, то це не математичне додавання функцій, з'являються якісь унікальний сверхсвойства, про яких не можна не говорити. Навіть на нашому курсі, який перший у списку авторизованого навчання, ми про цих функціях будемо досить багато говорити. Тому ці речі потрібно позиціонувати: що є що і яку роль займає. Продукти буду перераховувати і описувати в певному, не випадковому порядку.



Спочатку поговорю про Networker. Це головний продукт – ядро, системи захисту даних в частині системного копіювання та архівування. По суті – це класичне многозвенное клиентсерверное засіб резервного копіювання, програмний комплекс. Дистрибутив, елементи, ланки якого розкладаються на: резервні копії у вигляді клієнтів, сервера резервного копіювання у вигляді вузлів зберігання, до яких підключені якісь сховища, які пов'язані з клієнтами якийсь середовищем передачі даних. Пускаючи це буде LAN або SAN, щось в цьому дусі. І є майстер-сервер, який ми називаємо бекап-каталогом. Є централізовані кошти, де є сервер, який веде єдиний облік резервних копій, носіїв інформації, на яких вони потрапили, де зберігаються політики резервного копіювання, правила, що автоматизує весь цей процес. Фактично, на цьому ланці, яке називається – Networker сервер, самих тіл резервних копій не зберігається, тільки їх облік і контроль. Сюди «тыркаются» різноманітні адмінських консолі і т. п. Зв'язок усіх ланок здійснюється, природно за протоколом ТСР/IP через локальну мережу, через глобальну мережу – не важливо. Нас, природно, цікавить питання руху трафіку резервного копіювання.

Ось у нас джерело резервних копій – щоб це не було, і у нас destination. Як вже було сказано, засоби резервного копіювання Networker – корпоративного класу, це значить, що воно вміє відокремлювати одне від іншого. Трафік резервного копіювання може передаватися по виділених сегментів – інтелектуально і усвідомлено. Звичайна локальна ethernet-мережа або який сторедж эриа нетворк, що працює за fiberchannel — будь-який спосіб зв'язку. Це означає, що Networker знає, що таке LAN Backup Free, чули про таке, так? Що ще може робити Networker? Наприклад, бекапить джерело резервних копій не навантажуючи його. Особливо поширюватися не буду, це називається serverless або proxy backup. Те, що я перераховую ці функції, це не означає, що їх тільки Networker може робити, це означає, що він ними володіє, як і його конкуренти. Networker може бекапить NASы, за рахунок того, що знає, що таке NDMP, протокол NDMP freeware backup – хто не знає що це таке? Це реалізація lanfree serverless для виділених файлових «смітників». Networker породившись в 1989 році, має довгу історію і його матриця сумісного ПЗ та обладнання – дуже велика. Він розрахований на гетерогенну мережа, у нього в джерелах може бути що завгодно, дуже велика матриця сумісності: різних ОС і бізнес-додатків, яку він може бекапить без зупинки, то що називається онлайн-бекап, у нього величезна кількість різних інтеграцій, включаючи різні Microsoft та інші.



Традиційно, Networker, в якості резервних копій використовував роботизовані стрічкові бібліотеки в першу чергу – в цьому він досить гарний, у нього матриця сумісних бібліотек дуже велика. Ніхто не каже, що він не може бекапить на диски – звичайно може! Але ми знаємо, що на дисках зберігати бекапи – дорогувато, особливо при поточних обсягах. Я це кажу до того, що спочатку Networker був розрахований на роботу з стрічковими бібліотеками і досі з ними краще всього працює. І для традиційного підходу до захисту датацентрів – це цілком нормально. Економічно легко довести доцільність використання Networker для захисту бойових серверів, які сидять в Цоді: всякі Ораклы, Сіквела, сервера додатків, величезні дані, які в межах ЦОДа, за високошвидкісний, виділеної якийсь мережі, ми ганяємо на які сховища резервних копій. Все добре, але Networker, так вже вийшло, знає, що таке дедупликация, але не вміє самостійно виконувати. Не тому, що про це не подумали розробники, а тому, що до того моменту хто-то вже вмів цю дедупликацию робити. Тому, якщо ви хочете для якоїсь частини джерел резервних копій організувати ефективне потокове стиснення, то в якості одного з безлічі сховищ, з яким може працювати Networker, ви можете використовувати Data Domain, тому що це, фактично, дискова полку з вінчестерами, з якоюсь, будемо вважати, апаратної дедупликацией, яка дозволяє дуже ефективно стискати потоки резервних архівних копій, які валяться на цю полицю.

Відповідно, у цього ящика є маса інтерфейсів, про які ми будемо говорити докладно. Думка залишається колишньою – єдиний господар, єдиний облік резервних копій, частина з них падає на якісь традиційні сховища, а частина падає на сховище з дедупликацией, дискової дедупликацией. Потрібно розуміти, що дедупликация – це не панацея і економічно доцільно використовувати її в цілому, і ось такі продукти. Якщо ми використовуємо традиційний похід – стрічки, відчужувані носії з послідовним доступом, то там швидкість відновлення, як ти не изгаляйся, буде вимірюватися годинами. Якщо цей показник Recovery Time Objective потрібно звести до якогось прийнятного мінімуму потрібно зберігати резервні копії на дисках – але це дорого, тому давайте застосовувати дедупликацию, якщо вона застосовна, звичайно ж – джерело резервних копій може бути з протипоказаннями до стиснення – не горнеться, і все, і хоч убейся. Тут відразу ж приходить в голову резонна думка: коли говорять про використання чого-небудь з дедупликацией, потрібне обстеження автоматизованої системи замовника в рамках якоїсь методики та обґрунтування – оцінка цього досяжного коефіцієнта. Якщо обстеження немає – що ви можете очікувати? Хтось каже, що він може «гарантувати» якийсь коефіцієнт стиснення – дивно це чути! Звичайно ж чистий маркетинг. А в реальному житті не так все просто.



Data Domain може виконувати дедупликацию самостійно, своїми силами, витрачаючи свої процесорні тики, свою процесорну силу, оперативну пам'ять — не напружуючи джерело. Це дуже добре. DD може приймати потоки резервних копій через LAN, через ethernet – 10 гігабіт, 40 гігабіт заявлено. А може при необхідності делегувати частину функцій, пов'язаних з обробкою, на саме джерело – якщо це допустимо. Інтерфейсів у Data Domain багато — для прийняття одночасного потоку безлічі резервних архівних копій, але найефективніший – це ліцензований інтерфейс DD Boost, цей протокол і Data Domain невіддільні. DD може використовуватися без DD Boost, але сам цей інтерфейс може використовувати тільки в DD.

Data Domain економічно доцільний, це легко довести, використовувати для захисту, все-таки серверів, які сидячи в Цоді, які пов'язані з DD якоїсь загальної, високошвидкісний середовищем передачі даних, це не VAN, це LAN або SAN. Знову ж таки, мова йде тільки про серверах, для яких допустима дедупликация, а якщо ні, тоді потрібні диски. Ось така проза життя, загалом-то.

Бойові сервера, для яких дедупликация не застосовується, для яких показник RTO не такий жорстокий, їх цілком нормально бекапить на роботизовані стрічкові бібліотеки і т. д. Є джерела резервних копій, для яких показник RTO критичний, їх потрібно мати можливість швидко відновлювати, цього вимагає політика безпеки і для них немає протипоказань дедуплікаціі – купили Data Domain і сказали Networkerу частину потоків резервних копій з цих джерел направляти на такі сховища

А що робити з третьою категорією джерел резервних копій і найчисленнішою? – з робочими місцями? І якщо їх пов'язують з сховищем ненадійні канали зв'язку? Працюють з перебоями, то пропускна здатність слабка і т. д. Бекапить їх традиційним способом і з дедупликацией на сховища – марно, дуже незручно. Тут ЕМС каже, гаразд, у нас є ось такий продукт — Avamar, який звичайно може бути використаний автономно – і для захисту і серверів він підходить, і для захисту чого завгодно. Але його особливість в тому, що він завжди виконує стиснення на джерелі. Спочатку, напружуючи джерело, стискаючи, наскільки це можливо, дані підлягають резервного копіювання, а потім тільки вже в стислому вигляді передає унікальну дельту, копію в якесь сховище. Avamar, в частині інтеграції, може працювати зі всіма продуктами сімейства, може також дуже ефективно працювати під управлінням Networker.

Враховуючи, що воно все одне з одним інтегрується, всі категорії джерел резервних копій захистити – можна технологіями від єдиного постачальника. Залишилося тільки що? – кореляція подій, які відбуваються в цих складних програмно-апаратних комплексах, з подіями, які відбуваються на мережевому обладнанні, сховищах, системах зберігання даних і т. д. Для того, щоб відповідати тому, що називається SLA, по-друге для того, щоб можна було організувати billing. Ідея дуже проста – всі вищеперелічені продукти, окремо, і у сукупності, вони те, що називається cloud ready. Це означає, що з них можна побудувати хмарний сервіс резервного копіювання і здавати його в оренду. Я – оператор, побудував свої сервер-Цод, поставив туди цих продуктів і здаю вам, як юрособам в оренду. Щоб вам гарантувати рівень якості обслуговування і кожному виставляти рахунки, по мірі використання моєї інфраструктури потрібен біллінг. Для організації цієї частини нам потрібен такий продукт – Data Protection Adviser (DPA), порадник. Це окремий програмний комплекс, клієнти якого ставляться на всі джерела інформації, у якого є централізована БД, куди збирається вся інформація, де вона семантично укрупнюється, звіряється з якоїсь БД сигнатур якихось подій. Ну і далі сидить хтось, хто дивиться на монітор, і йому показується червоним кольором – все погано, або йому вказується, даються поради – що робити? І він пише звіти, або виставляє рахунки начальству — відмінна річ.

З чого складається Data Domain

Я перерахував всі модулі єдиного модульного продукту, оскільки часу у нас не так багато. Але якщо є ті, хто хоче себе показати RTO звести до нуля. Є продукт Recover Point, який знову ж з усіма інтегрується, зокрема з Networker, які реалізують концепцію безперервної захисту.

У нашому курсі акцент буде зроблений на малу частину цього програмно-апаратного комплексу – тільки Data Domain. Але завжди ми будемо говорити про нього у світлі інтеграції з іншими продуктами із сімейства, або від сторонніх виробників, що теж не проблема.

Серед вас багато досвідчених хлопців, хто вже працював з конкурентами Data Domain. Якщо спробувати визначити, що таке Data Domain, то можливо вийде так: дискове сховище дедупликаций для зберігання резервних, архівних копій. Не більше і не менше. Це дуже важливий момент. Це не СГД, порівнювати її з чимось таким немає ніякого сенсу. Бо то — сховище для зберігання робочих даних, для яких профіль навантаження, загалом те, як би універсальний: там можливо і послідовне читання, запису, і довільні читання, запису. Там ці серйозні показники iops, ті, хто працює з СГД про це знає. У СГД, які б вони не були: слабкого, середнього, високого класу – при всіх інших рівних, є якась загальна архітектура. Фронт-енд, є якийсь кеш, бекэнд, є відмовостійкість, мультипафинг тощо. Data Domain – це не СГД, ніколи його так не називайте це гріх:)

Data Domain – це сервер. Якщо я беру це залізо, то я бачу програмно-апаратний комплекс, є апаратна частина, у вигляді засобів обчислювальної техніки, програмна частина у вигляді системного це ОС, є якесь там прикладне ПЗ.
Апаратна частина це що? Інтеловський чіпсет, пам'яті як можна більше, пару блоків живлення, там є шина PCI express, скільки-то слотів, у материнську плату вбудований 4 мережевих карти з гігабітними інтерфейсами і 2 мідних з 10 гигабитами. За замовчуванням вже є більше ніж 1 надлишкових мережевих інтерфейсу для підключення до зовнішнього середовища, щоб приймати управляючий трафік, щоб приймати потоки резервних копій і видавати потоки відновлення. Вже добре. В слоти ми можемо увіткнути ще мережевих карт, в залежності від моделей, потужність теж може бути обмежена чіпсетом. Можна увіткнути fibre channel host bace adapter, правда за окремі гроші, я бачив такий адаптер 4х і 8ми гігабітний, 16гигабитный хтось бачив? Я бачив, що їх заявляли, як і 40гигабитные ethernetы, але поки що їх немає, їх можна очікувати.

Що ще на шині є? Там за замовчуванням там вже стоїть дисковий контролер, SAS і не один, їх повинно бути 2. На шині яких висять якісь диски, дисковий масив. У молодших Data Domain моделях це прямо в корпусі самого сервера, який монтується в стійку. Скільки там вінчестерів? Мінімум – 7, максимум – 15. Якщо у вас модель Data Domain більш серйозна, ви можете на шину SAS-контролерів, ще додати одну або кілька дискових полиць. В дискових полицях крутяться, раніше це був убогі sata-вінчестери, зараз це NL SAS-вінчестери. Чим NL SAS від SAS відрізняється? NL SAS – це дешевий SAS (саташный гвинт, зроблений через SAS шину, швидкість обміну збільшили, але саму архітектуру гвинта залишили як і було). SAS, грубо кажучи, це старе добре scsi. NL SAS – це сасовские вінчі, які за результатами виробництва не пройшли якихось жорстоких випробувань на продуктивність, надійність, але мають якийсь прийнятний рівень, тому вони йдуть дешевше. Грубо кажучи, у сасовских винчей час напрацювання на відмову в рази більше ніж у NL SAS. Я кажу не про продуктивності, а про надійність. Ці вінчестери, яких багато, десятки або сотні, вони, природно в якісь рейд масиви зібрані. (Кожна полиця збирається в окремий рейд масив) це ще називають дисковий групи (залізних контролерів там нема, фактично це софтовый рейд, це не погано і не добре, це просто так працює, і в кожній полиці ще додатковий диск hot spare). Я бачив, що в head парочка дисків виділена під ОС. (Раніше такого не було, зараз у більш старших моделях Data Domain використовується 4 диски для цієї Data Domain ОС. Вони винесені окремо, там змішані рейди). Там корисні дані не зберігаються там тільки службові.

Якщо згадати логіку побудова рейд 6 масивів. Які там накладні витрати? Одна логічна операція запису якогось блоку даних – це скільки фізичний операцій (я говорю про iops)? 3 читання + 3 запису. Тобто накладні витрати – дикі! У 6-го рейду накладні витрати найбільші, у 5-го менше: читання 2 + 2 записи. Дискова система в цьому сервері – дуже повільна, тому ми згадуємо про те, що ми говорили, що це – не СГД.

ОС – це якась лінукс-подібна операційна система, називається DD OS (Data Domain Operating System). У загальному випадку, для звичайного кастомера, споживача вона доведена до невпізнанного виду – традиційних шелов ви там немає. Там простецький командний інтерпретатор, з якоюсь системою команд з простим синтаксисом. І якщо ти не інженер, а служба техпідтримки, та інженерного доступу не маєш – то забудь про більшість відомих тобі юниксовых команд і утиліт. В якості програми буде термінал різноманітних демонів: Daemon VTL, Deamon DDBoost, Deamon NTP, Deamon NFS і так далі. Комплект яких вбудований в цей дистрибутив лінукса, щоб через різноманітні протоколи рівня додатки брати/віддавати потоки резервних копій.



Чому Data Domain такий дорогий?

Добре, тоді питається чому Data Domain такий дорогий? Що тут такого особливого в частинах, з чого я не можу сам зібрати? Не беремо в розрахунок маркетинг і т. д., якщо взяти до уваги технічну частину – в одному з слотів PCI коштує одна або кілька спеціальних плат, які називаються NVRAM плати. Спеціалізована плата, з якимось об'ємом оперативної пам'яті в чіпі, 1 гігабайт, 2, 4 гіга, з яким-то, будемо вважати спеціалізованим мікропроцесором. Це та сама плата, з допомогою якої ось ці потоки вхідних резервних архівних копій, за допомогою центрального процесора – скорочуються. Та сама плата, де проходиться та сама дедупликация. Це те, що дозволяє старшим моделям DD «ужирать» в годину десятки терабайт даних. Уявіть собі 10 терабайт в годину вхідний потік, і яка повинна бути продуктивність дискової підсистеми, зібраної з NL SASов в рейді 6? Так їх там має бути неймовірна кількість!

Але як старших так і молодших моделях Data Domain дискова підсистема по продуктивності не відрізняється. Сумарна кількість иопсов, яке воно може видавати – воно залишається маленьким. Абсолютно неадекватним тому набору функцій, які потрібні для такого обсягу даних. Всі ці «пекельні» терабайти стискаються на вході до прийнятного рівня, і до дискової підсистеми доходить лише прийнятна навантаження. Технологія дедуплікаціі, точніше її реалізація в Data Domain, запатентована.

Якщо злітати в Каліфорнії в Санта-Клару, де це підрозділ, зараз це називається Data Protection and Availability Division, колишній BRS, то там у холі, є «зал слави», де висять всі ці патенти, їх копії. А це дороге задоволення, ви, купуючи Data Domain, оплачуєте всі ці патенти, власнику патенту, за його суперразработку, яка в певній частині тримається в секреті, ми про це поговоримо пізніше. Не хочу сказати, що в інших вендорів аналогічних технологій немає, але порядок цін такий же як і на Data Domain. Всі вони б'ються з усіх сил за споживача. Основний конкурент – HP Storeonce і IBM Protectier.

Тобто Data Domain буде виглядати так: сервер, з полицями або без полиць, підключений через ethernet тільки, або й через ethernet і fiberchannel, що приймає потоки резервних копій через безліч різноманітних протоколів. Виходить, що основною конкурентною перевагою цього продукту, по суті є дедупликация.



Дедупликация

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

Відповідно у нас дедупликация може виконуватися на різних рівнях абстракції. Те, що я розповідаю не ново, але це потрібно щоб говорити в одному і тому ж словнику.

1) Filebased. На рівні файлів. Ви всі бекапите на мене якісь дані, а я шукаю якісь повторювані файли. Прийшов якийсь файл від кого-то, з'ясувалося, що він мені ніколи не зустрічався, він унікальний – я поклав його в сховище. Витратив якісь ресурси, місце в сховище, щоб тіло цього файлу там розмістити. Від кого-то прийшов ще один примірник цього ж файлу, я якимось чином в цьому переконався. І замість того щоб витрачати ресурси, я зберігаю метаінформацію що такий файлик зустрічається там-то і там-то. Накладні витрати будуть на 2 порядок менше, замість того щоб зберігати тіло файлу в сховище.

А як звіряти файли? Найпростіший – це побітова звірка, її не можна скидати з рахунків, у певних випадках вона ефективніше ніж розрахунок еталонної характеристики, хеши і т. д. Тому ніколи це не упускайте, я про це розповім трохи пізніше. У більшості систем резервного копіювання використовується такий підхід: давайте ми ось цей набір даних проженемо через якусь функцію, і незалежно від того, який розмір вихідного набору даних, ми отримаємо якийсь хеш, еталонну характеристику фіксованого розміру. І в рамках цієї математичної залежності у нас буде певна гарантія того, що якщо у вихідному наборі зміниться один біт, результат хешування буде зовсім інший. Я спеціально піднімаю це питання, в навчальних матеріалах курсу ви цього не побачите, щоб вам сказати наступне: так, функція хешування має пряме відношення до симетричної криптографії, це окремий клас математичних функцій. І для них актуальна проблема колізій. Ймовірність того, що у різних наборів даних буде один і той хеш – не нульова. Але її можна звести до прийнятного мінімуму. І для тих випадків, коли ці колізії трапляються якимись компенсуючими заходами гарантувати, що цілісність даних не буде порушена. Я спеціально це кажу, тому що, зокрема, в Data Domain, розробники цього питання приділили увагу, і дають математичну гарантію, доказ того, що ці колізії не проблема, і з ними справляються з допомогою компенсуючих засобів.

В цьому випадку всі унікальні набори даних мають унікальні хеши. Якщо відбуваються колізії – цим можна знехтувати. Це доведено, мова йде про запатентованої технології, не зі стелі це взято. Який алгоритм, що перевіряти чи не перевіряти – ми не знаємо. Я спеціально повторюся, алгоритм дедуплікаціі (він великий, якщо намалювати схему – кімнати не вистачить) це враховує. І про це кажуть розробники.

Ця технологія, так би мовити, «тупий», але дай бог, якщо можна отримати коефіцієнт стиснення в 1,5-2 рази. Це середній показник, але чекати тут хоч чогось-вкрай складно. Навіть якщо у вас в якості джерела резервних копій якась файлова «смітник», багато повторюваних файликів.

2) Якщо у мене на чолі стоїть коефіцієнт стиснення, то давайте шукати не файли, а блоки даних фіксованої довжини. Давайте всі дані, що нам падають кришити на фіксований шматочки, зазвичай в кілобайтах. Для кожного шматочка розраховуємо хеш, і звіряємо з хешами тих шматочків, чиї тіла лежать в нашому сховищі. Є попадання – ок, він зберігся, не будемо його зберігати, немає попадання – це шматочок унікальний, пора його помістити в сховище.

Цей підхід гарний ніж, що мізків не потрібно багато включати. Але він найкраще працює для джерел резервних копій, де дані структуровані. Якщо той набір даних, де ми шукаємо змінені блоки, він вже спочатку в нього вносяться зміни фіксованими транзакціями, фіксованого розміру, то це дуже зручно. У понеділок були одні блоки, то вівторок блок такий-то і такий-то змінився. Коли у вівторок засіб резервного копіювання покришить цей файлик на шматочки фіксованого розміру, він суворо локалізує зміни.

Коефіцієнти стиснення, які можна досягти при цьому підході вже більше. В середньому це може бути 2-5 разів. Але тут важливо щоб джерело задовольняла певним вимогам, де дані структуровані і зміни робляться фіксованими трансакціями певного розміру. Найчастіше це СУБД. Для таких даних видаються хороші показники. А якщо неструктурований виннигрет? Алгоритм не зможе локалізувати ці зміни, тому що там все зсувається.

3) Тому є алгоритм дедуплікаціі на блоки даних варіюється розміру. Суть цього алгоритму — локалізувати зміни. Навіть якщо на початку або середині файлик змінився, система зрозуміє, що це тільки ці блоки помінялися, а інші залишилися колишніми. Зазвичай такі алгоритми використовують дані, блоки яких варіюються 4к-32к. Є гарантія того, що якщо вихідний набір даних не змінився, то результат його «крошилова» буде одним і тим же. І він зможе локалізувати тільки змінену частину даних. Всі ці алгоритми подібного роду – запатентовані. Вони всі тримаються в секреті. По суті, це всі варіації того, що називається фільтр Блума – якщо захочете свій математичний апарат напружити. Тому частина патентів в Санта-Кларі, вони про це. Про запатентованої реалізації системи теорем. Хтось реально напружив свій мозок.



Тепер, якщо говорити взагалі про дедуплікаціі, на якому рівні абстракції її краще виконувати? 1-й, 2-й, 3-й спосіб… ні, невірно, немає «правильного» відповіді. Приблизний правильну відповідь звучить так: ідеальний засіб резервного копіювання має вміти виконувати дедупликацию на всіх рівнях абстракції, підлаштовуючись під особливості джерел резервних копій.

По простому: у мене файлова «смітник», неструктурована інформація бекапится? Давайте я спочатку швидко, нікого не напружуючи: знайду повторювані файлики і їх викину, ті які унікальні – гаразд, почну кришити. Якщо це файлик – тіло БД, то я його буду на структуровані файлики кришити певного розміру, якщо неструктуровані блоки на блоки даних варіюється розміру. Тому що завжди доводиться шукати компроміс між коефіцієнтом стиснення і накладними витратами, навантаженням на це стиснення.

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

Наприклад, для цих даних – їх потрібно максимально стиснути, я для цього важливо, щоб при стисканні це вкладалося у вікно резервного копіювання, а для цього важливо час відновлення. Так от, Networker в поєднанні з Data Domain і Avamar і представляє таку інтелектуальну систему резервного копіювання.

Було питання щодо Мicrosoft

В Microsoft, в ОС, 2012 версії у разі встановлення ролі файлового сервера є опція, яка реалізує дедупликацию блоків даних варіюється довжини на рівні тома. І там коефіцієнти 1,5-2%. Якщо ми говоримо про Avamar, то він виконує дедупликацию на всіх 3 рівнях абстракції, якщо про Data Domain, то він виконує дедупликацию завжди на 3м рівні — блоків даних варіюється довжини. Алгоритм хешування, який використовується – промисловий – Secure Hash Algoritm, і розмір еталонної характеристики 160 біт.

Йдемо далі. У нас вже була візуалізована архітектура класичного сучасного засоби резервного копіювання корпоративного класу – клиентсерерное, многозвенное. Є безліч джерел – клієнтів, є якась середовище передачі даних, що зв'язує ці джерела з тим, що називається медіасервера, вузли зберігання, які підключені до сховищ. І є якийсь бекап каталог, який диригує всім цим.

Так от, в частині що стосується дедуплікаціі. Вона може виконуватися ким? Хто цей герой? Є варіант postbased. От є терабайт даних, він передався через якусь середу на сховище, у відведений бекап вікно, воно з'їло терабайти даних, для цього йому потрібно багато шпинделів, витратилася місце терабайт, а потім вже напевно поза вікна резервного копіювання починається це ужимание: на рівні файлів, блоків даних фіксованих і т. д. – але цим напружено саме сховище. І ось він звузився у 10 разів, 100 гигов є. Добре це чи погано – я не кажу. Наприклад Windows Server 2012 саме так і працює. VNX працює схоже, але останні моделі можуть робити дедупликацию, не тільки на рівні файлових блоків, але і на рівні лунов – і він за своїм розкладом це робить, і ми економимо наше дороге місце.

Є дедупликация «на ходу». Терабайт прочитали, передали через середовище передачі, ніякої економії немає, але перед тим як потрапити в дискову підсистему сховища, цей терабайт, з допомогою процесора, оперативки, скорочується, і ми прибираємо це божевільна кількість иопсов, і отримуємо якесь їх адекватне кількість, яку можна писати на дискову підсистему. Не потрібно багато шпинделів, не потрібно купа місця. Ось це у нас – Data Domain. Він це може робити через будь-які програмні інтерфейси.

Третій варіант. Дедупликация на джерелі. Терабайт я прочитав і тут же напряг джерело. Він і так напружений читанням великого масиву даних, передачі їх кудись, а тут їх ще потрібно стискати. Ось дотиснув він це до 100 гигов і вже нещасні 100 гигов передав по системі передавання даних у сховище. Це вміє робити Avamar і Data Domain у разі використання інтерфейсу DDboost з включеним функціоналом DCP. Тобто Data Domain знає, що таке дедупликация на джерелі. Найцікавіше, що він знає і що таке постдедупликация, перший тип, про який ми говорили. У Data Domain є час, коли він сам з собою розуміється, і ось це також передбачає postbased дедупликацию.

Безліч потоків, які валяться на Data Domain, він їх кришить, на шматочки варіюється розміру, розраховує їх на хеши, звіряє їх масиви. Але є математична гарантія того, що для 99% цих шматочків, він зможе зрозуміти унікальні вони чи ні. А для 1% він цього не зможе зробити вчасно. Вважайте, що він ці шматочки куди покладе, щоб встигнути, а потім їх ще постфактум дотисне. Як і чому це трапляється я поясню потім. В цьому немає нічого поганого, це ніхто не декларує, але ніхто від цього не відмовляється. Ті свідчення продуктивності для кожної моделі Data Domain, які викладені на сайті ЕМС – це не чистої води маркетинг. Вони зробили лабораторію, програму методики випробувань, живий Data Domain поставили, і стали на нього щось бекапить і досягли цих результатів, суворо їх виміряли. Зрозуміло, що при дотриманні певних умов, можливо навіть ідеальних, але ніхто не обіцяє манну небесну. Всі кажуть: проводите дослідження, обосновывайте, доведіть замовнику, що саме такий коефіцієнт буде отримано, така швидкість поглинання буде отримана в його ситуації – і ось це продавайте.



Те, що я розповідав – це якийсь лікнеп щодо коштів резервного копіювання. education.emc.com – портал навчання, ви напевно про нього знаєте, добре туди заходити частіше. Є відмінний курс Backup Recovery Systems and Architecture, займає 40 годин. Курс з основ резервного копіювання та архівування, там про ось цю многозвенность, про serverless проксі бекапи, дедупликацию, там багато чого написана. Курс насправді університетський, читається на старших курсах технічних Вузів, партнерів академічної програми ЕМС, викладається магістрам, в рамках другої вищої. У пітерському політесі, в московських вузах я такий курс читав. Курс сам по собі дуже цікавий, я спеціально про нього кажу, тому що було б бажано, щоб кожен з вас хоча б його перегорнув і подивився. Тому що білі плями в освіті є у всіх. Займаючись більше 10 років системами захисту, я думав, що на цьому собаку з'їв, що мене вже нічим не здивувати – ан немає. 5 днів – 40 годин, тільки про ось ці основи.

Йдемо далі. На сайті ЕМС в розділі захисту даних я дивлюся номенклатуру продуктів. Під захистом даних розуміється їх цілісність і доступність в першу чергу. Не конфіденційність! Коли йдеться про всякі секрети це йдемо в RSASecurity. У мене тут є дюжина продуктів і в розділі backup recovery у мене є ЕМС Data Protection Suite – це і є єдиний програмно-апаратний комплекс для захисту всіх категорій даних.



Я хочу подивитися на моделі Data Domain і подивитися на їх характеристики. Моделей дуже багато, на будь-який смак і гаманець. Хочу подивитися саму слабку модель — Data Domain DD160. У ній є 7 дисків за замовчуванням, або можна розширити до 12. Архітектура у всіх моделей Data Domain однакова, але у тих, що подешевше є певні обмеження. Наприклад, полку не додаси – обмежена можливість масштабування, багато мережевих інтерфейсів там не поставиш, hostbased адаптерів. І ось configuration maximum – 160 модель готова сумарно поглинати потоки резервних копій зі швидкістю до 1терабайт/год. Як інтерпретувати цей показник? За умови? що потік йде через ethernet і DDboost, DCP включений, з дедупликацией на джерелі. Якщо немає DDboost, то можете сміливо ділити на 2: вхідний і вихідний. DDboost вже працює багато з ким, навіть HP Data Protector вміє з ним працювати, Internet давно знає, Backup Exec давно знає – це промисловий стандарт, тому що інших альтернатив не придумали.

Що таке 195 тб Logical capacity? Як це інтерпретувати? Тобто до стиснення майже 200 гб, а ємність у нього 1,7. Який потрібен коефіцієнт стиснення? Якщо грубо округлити – у 20 разів? У мене є замовники, у яких: в 3 рази пожалось – круто!



Протипоказання

Чому я на це звертаю увагу – ще раз кажу – все залежить від даних. Коли говорили про дедупликацию я спеціально не згадав про протипоказання. Якщо, наприклад, у мене є дані зашифровані, спочатку представлені у вигляді криптограми, а я їх бекаплю. Які ми отримаємо коефіцієнти стиснення? Алгоритми шифрування і алгоритми компресії – з однієї категорії математичних функцій. Вони роблять приблизно одне і теж, але цілі у них різні. У одних забезпечити конфіденційність, а у інших зменшити їх обсяг. Все що зашифровано – протипоказано для стиснення, так як після нього дані займуть ще більше місця.

Добре, якщо дані стиснуті вже. Мультимедія, все що завгодно. Будь коефіцієнтів можна очікувати? Можна очікувати, але тут все залежить від схеми резервного копіювання. Якщо у мене є медіа архів, об'ємом 10 тб, який не горнеться, але я кожен день роблю фул-беэкап, це не варіант – цього ніхто не робить.

Тому потрібно виявляти протипоказання, там де їх немає – проводити обстеження. І обчислювати ось цей досяжний коефіцієнт стиснення. В якійсь мірі його можна обчислити емпіричним шляхом, подивитися на дані, у ЕМС є статистика і сказати: в 5 раз пожмется. Від цього можна відштовхуватися. У вас там SQL і Exchange, стільки-то поштових скриньок такого-то розміру? Є формула, куди це забиваєш і отримуєш результат.

Все чіпали Backup System Sizer? Він дає приблизну прикидку. Мої замовники діляться на 2 категорії, одні кажуть: напиши нам докладно на документах, обґрунтуй, технічне обґрунтування і т. д. А інші кажуть: нам нічого не треба з документів, але ти особисто відповідаєш за те, що пообіцяв? В ідеалі, звичайно, щоб відповідати за свої слова, потрібно точно самому переконатися, що вийде саме той коефіцієнт стиснення.

Тоді краще зробити те, що не дуже люблять робити інтегратори: дайте замовнику в дослідну експлуатацію хоч слабенький, хоч б/у, Data Domain. Нехай він там покрутиться якийсь час, і ми за фактом подивимося який вийшов коефіцієнт. І вже цього будемо відштовхуватися, розробляти техніко-комерційну пропозицію.

Документація і навчання

До чого це все. Без етапу проектування – не обійтися. Хтось має провести обстеження в рамках якоїсь розробленої методики, написати технічне завдання на систему захисту. План захисту, положення і категорування інформаційних ресурсів. План забезпечення роботи, відновлення після збоїв. Всі ці документи повинні бути. Хтось повинен оцінити, сказати, наприклад, що ось ця категорія – там дедупликация не потрібна, тут можна – але не навантажувати джерело, тут можна, тут такий коефіцієнт, тут такий.

Цю роботу робить інтегратор, або партнер, як їх називає ЕМС. У ЕМС є спеціальна навчальна програма для архітекторів, проектує для тих, для інженерів-конструкторів. Де всьому цьому навчають: обстеження та складання технічної документації. ЕМС працює на рівні планети – у них все стандартизовано. Інженер і в США і в Україні працює за однаковими зразками. Нічого не потрібно вигадувати.

Але, не кожен це просить замовник. Тому якщо ви замовник ви повинні у інтегратора просити цей пакет документів. Не довідкову інформацію з сайту, а описи технології виготовлення і обслуговування цього виробу. Якщо ви працюєте в інтеграторі – все є, тільки треба спитати.

Для пуско-наладчиків, тих, хто по документації виготовляє виріб – є свої курси навчання, ми на одному з них знаходимося. Це зазвичай інженери з партнерів і з самого ЕМС.

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

Все це розписано на порталі навчання ЕМС. Навіть якщо ви кастомер, вам доступно там багато чого. Особисто я можу поділиться прикладами конструкторської документації, тому що з чистого аркуша їх написати складно. Тому доводиться підтримувати інженерну інтелігенцію, тому що господарі не люблять за це платити гроші, але це потрібно, тому що це окремий вид діяльності.

Або ти сидиш в інтеграторі і потоково створюєш ці комплекти документів, що або ти знаходишся у великому замовники і для тебе це як перший раз. Навіть якщо ти виступаєш в ролі представника замовника і контролюєш дії підрядника, потрібно розуміти, що від нього потрібно вимагати. Тому краще знати що робити.

За всіма етапами життєвого циклу автоматизованої системи в частині її системи захисту – у ЕМС є програма навчання та сертифікації за всіма їх продуктів. Чи Будете ви інші курси розглядати – це вже треба дивитися.

Адміністрування ЕМС Data Domain: введення в курс

Ввідні у нас ставилися до основ систем системного копіювання та архівування. Ми, фактично швидко пробігли зміст університетського курсу, або навчального 5дневного курсу по архітектурі цих систем. Заодно подивилися дедупликацию. Строго позиціонували Data Domain у номенклатурі продукції ЕМС. Зробили висновки – чого від нього чекати і чого від нього чекати не варто – що найважливіше.

З назви нашого курсу очевидно, про що ми будемо говорити. Якщо подивіться на нашу модель життєвого циклу, то мова йде про підтримку, обслуговуванні, вже, фактично готового чорного ящика. Який хтось: спроектував, як він буде вбудовуватися в існуючу або нове середовище, розписав комплект конструкторсько-експлуатаційної документації. Хтось з цього комплекту здійснив збірку, монтаж, пуско-наладку цього виробу, хоча б у загальній частині і далі це було передано персоналу замовника разом з документацією. Замовник здійснює адміністрування, в малій, вузькою мірі, в якомусь коридорі він здійснює донастройку. Але основне завдання цього персоналу – моніторинг. Ми звіряємо поточний стан цього ящика, з еталонним, яке було зафіксовано на етапі здачі в експлуатацію.

Траблшутинг

Якщо поточний стан не відповідає еталонному – виявляємо причину, усуваємо несправність. І далі все це йде по циклу. Заново допрацьовуємо ТЗ — версія 2.0. Бо щось змінилося, ризики змінилися, життя змінилося. І за такого циклу і розвивається система захисту. Нормальна, зріла компанія цей цикл проходить вже 5й або 7й раз, не роблячи все з нуля, а розвиваючись. Це актуально для будь-яких інших виробів.

Наш курс – певний проект, є початок, є результат. І тому мені треба визначити межі цього проекту: про що ми будемо говорити, не будемо говорити. Про проектуванні ми говорити не будемо, так як про це є інші курси. Про пуску-наладки ми будемо говорити лише в частині, що стосується кастомера. Є окремі курси для інженерів ЕМС та партнерів-інтеграторів, де розписано: як зібрати ось цей Data Domain, вмонтувати з комплектом полиць у стійку, як отмаркировать, підключити всі ці сполуки, як створювати рейд-масиви, як залити образ ОС, як здійснювати інженерне техобслуговування, яке не безкоштовно.

Ми, як кастомеры, говоримо, що нам хтось зібрав, призначив IP для керуючого інтерфейсу, хтось поставив пароль вбудованої учеткі адміна і передав нам ці атрибути доступу. І ми в рамках наявної документації щось там допишемо. У нас акцент на адміністрування, в якійсь частині на налаштування.



Про що курс – зрозуміло. Цільова аудиторія – я вже озвучив, теж зрозуміло: і кастомеры, і партнери, і хлопці з ЕМС. Всі сюди ходять, тому що потрібно всім під єдині стандарти освіти підходити. Вхідні вимоги – я теж вже озвучив: це університетський курс, він є, де його знайти і що з ним робити ви вже уявляєте.



Саме цей курс – проект, то пам'ятаємо, що за результатами цього маленького проекту, у вас повинно бути якесь розуміння, теоретичні знання, практичні, конкретні, навички, пов'язані з цим виробом. Це означає, що має бути вичерпне розуміння про дедупликацию: яка вона буває і як вона конкретно реалізована в конкретному виробі. Який комплекс запатентованих технологій є, не обов'язково має відношення до дедуплікаціі, реалізованої в Data Domain, він вартує своїх грошей, щоб ви бачив, що це за патенти.

Як моніторити цей чорний ящик, як їм управляти, через які адміністративні интефейсы до нього можна підключиться і можна почати з ним щось робити. Тут і командний рядок і GUI. Як розмежувати доступ до цього виробу. Data Domain – це багатокористувацький эплайнс, там багато людей повинні мати доступ до нього. Відповідно потрібно розмежовувати доступ і контролювати, не можна допустити щоб хтось щось зіпсував – це дороге обладнання.

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

Identify and configure Data Domain data paths – через які фізичні інтерфейси, логічні, Data Domain може приймати потоки резервних архівних копій – їх дуже багато. Давайте їх все перерахуємо, і для кожного їх них напишемо процедуру налаштування, проведемо випробування на стенді, щоб це опис відповідало дійсності, щоб було якесь доказ. У нас для цього є стенд.

Configure and manage Data Domain network interfaces – налаштуємо мережеву підсистему Data Domain. У найпростішій моделі надмірна кількість вбудованих в материнську плату мережевих інтерфейсів. Це добре, тому що можна забезпечити як мінімум – відмовостійкість, інтерфейси ламаються, обриваються дроти, а воно працює. А як максимум – агрегувати її пропускну здатність, підсумовувати інтерфейси для досягнення якихось результатів.



Одна справа — ініціалізувати Data Domain, інша справа почати кидати на нього якісь дані через різні інтерфейси. Будемо слідувати простою логікою: від простого до складного, від загального до приватного. Спочатку ми будемо чіпати прості інтерфейси, які легко налаштовуються і не вимагають окремих ліцензій. А далі все це буде ротивно ускладнювати. Наприклад, візьмемо і внутрішню файлову систему Data Domain і почнемо структурувати. З якогось великого шматка даних зробимо структуровану систему, щоб їй було зручно керувати.



Згадаймо, що Data Domain у загальному випадку – катастрофоустойчивое виріб. Коли писали ТЗ його розробникам, то дали завдання щоб Data Domain міг пережити повне знищення. Це що значить? — вчасно скинути репліку критичних резервних копій даних на інший Data Domain. Правда це річ ліцензійована.

Питання забезпечення безперервності бізнесу – дуже актуальні, особливо після 9/11. І люди задумалися: а що буде, якщо у мене буде пожежа або ще що?

Пам'ятайте показник RTO – щоб не сталося загубиться рівно стільки – не більше, і щоб не трапилося все повернути назад можна за стільки-то часу.

Тут було питання про що, одна з причин використовувати дисковий сховище для резервних копій – це поліпшення показника RTO, час відновлення. Наприклад, ми робили всі бекапи на стрічкові бібліотеки, тепер вимоги до безпеки змінилися, тепер дані потрібно відновлювати ще швидше, бібліотеки не працюють, що робити? Давайте подменим бібліотеку Data Domain, який буде на фронэнде виглядати як бібліотека, але з більш кращим показником RTO. Як зробити з одного або двох Data Domainов зробити одне або кілька віртуальних роботизованих стрічкових бібліотек? Як їх презентувати існуючих засобів резервного копіювання, щоб вони мінімально напружувалися?

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



Якщо ви не прив'язані до бібліотек, якщо у вас немає завдання підмінити фізичну бібліотеку віртуальної то купуйте Data Domain з ліцензованої функцією DDboost. Так як це для Data Domain рідний інтерфейс, який розкриває всі його можливості. Це найкращий варіант використання Data Domain. Це означає, що кошти резервного копіювання знає що таке DDboost, в гіршому разі, у кращому випадку це знають бойові бізнес-додатки, які бекапятся, це крутіше всього.

По-моєму, найбільш продавана конфігурація: це Networker з Data Domain через DDboost, вони виглядають дуже органічно. Але ми розуміємо, що DDboost – відкритий інтерфейс. ЕМС каже: нехай у вас буде ваш засіб резервного копіювання, але нехай вони знають, що таке DDboost, і для зберігання резервних архівних копій використовують наш оптимізований інтерфейс. Як його налаштувати – подивимося.

У нашому курсі буде лаба як по дружбі Data Domain з Networker через DDboost, так і лаба по дружбі Симантековского нетбекапа через DDboost з Data Domainом. Щоб продемонструвати цю гнучкість Data Domain.

Буде примана з проектування систем резервного копіювання для архітекторів, про які ми говорили. Якісь елементи методики підбору підходящої моделі Data Domain під вимоги конкретного замовника, їх модельний ряд великий. Ми зрозуміємо, що робота в цьому навіть присейла – не проста.

Кому буде цікаво далі поглибиться в питання проектування – знаєте у кого питати.



Ось наші модулі. Від простого до складного, від загального до приватного. У нас 10 модулів, але ще зробимо 11ї опціональний модуль. Почнемо зі знайомства, основ адміністрування, налаштування мережевої підсистеми. Продовжимо простими, не потребують ліцензій інтерфейсами – CIFS, NFS, яким можна ганяти трафік резервного копіювання та архівування. А далі будемо все це ротивно ускладнювати. Рухаючись до VTL і DDboost і до таких віщого захисту, які є в Data Domain, з допомогою яких можна забезпечити прийнятний рівень інформаційної безпеки. Відповідно до вимог законів та регуляторів.



Щоб визначити межі нашого курсу, ще раз скажемо про те, що – це програмно-апаратний комплекс. Є апаратна частина, є програмна. У апаратної частини є своя система ідентифікації – тризначні моделі, наприклад, 160 – це постарее, 4значные – новіші. А програмна частина визначається версією ОС – DD OS, поточна версія DD OS, яку можна завантажити з сайту – 5.5, а наш курс поки ще розрахований на 5.4. Так ось 11ї модуль з 10 буде про значущі зміни в 5.5. У кожної апаратної частини обладнання, є своя межа оновлення програмної частини.

В рамках цієї частини, поки що все.


Відеозапис


Курси ЕМС в УЦ МУК
6-9 липня в УЦ МУК буде курс за Data Domain System Administration, який буде вести цей інструктор — записатися на курс
А також:
15-17 липня — VNX Block Storage Management
21-25 липня — EMC NetWorker Microsoft Applications Implementation and Management


Дистрибуція рішень ЕМС в Україні, Таджикистані, Білорусі, Молдові, країнах СНД.

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

0 коментарів

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