Відновлення доменів даних та довгострокове зберігання у хмарі: Поширені запитання

Summary: У цій статті описано основні концепції довгострокового зберігання (LTR), конфігурацію та поширені запитання (FAQ), що стосуються функціональності LTR.

This article applies to This article does not apply to This article is not tied to any specific product. Not all product versions are identified in this article.

Instructions

У цій статті розглядаються найпоширеніші запитання щодо конфігурації та використання відновлювачів доменів даних (DDR) і довгострокового зберігання (LTR) або хмарних функцій.
 

Що таке LTR?
Для яких систем DDR доступний LTR?
Яка ліцензія потрібна для LTR?
Як працюють різні рівні?
Як структурований хмарний рівень?
Що відбувається протягом типового життєвого циклу резервного копіювання, коли налаштовано LTR?
Як відбувається дедуплікація даних між рівнями?
Що таке час розміщення (іноді його називають ptime)?
Як дані переходять з активного рівня на хмарний?
Коли починається рух даних, які фази є і які дії виконує кожна фаза?
Які політики переміщення даних доступні?
Як можна встановити політику переміщення даних на mtree?
Які політики переміщення даних вже налаштовані?
Як працює політика переміщення даних, керована додатком?
Як можна запустити переміщення даних вручну?
Як можна відстежувати рух даних?
Як можна зупинити рух даних?
Якщо хмарних блоків більше, ніж одиниця, чи може переміщення даних здійснюватися до обох хмарних блоків одночасно?
Як налаштовується LTR?
Чи можна видалити хмарний блок? Якщо так, то яким чином?
Що станеться, якщо хмарний блок не вдасться видалити через те, що об'єктне сховище більше не доступне або виникла проблема з підключенням?
Чи можна налаштувати LTR і ER (Extended Retention) в одній системі?
Як відбувається звільнення або очищення даних із хмарного рівня?
Як починається чистота ручного хмарного рівня?
Як можна контролювати очищення хмарного рівня?
Чи може активне багаторівневе прибирання виконуватися одночасно з прибиранням хмарного рівня?
Як можна відобразити або змінити графік прибирання хмарного рівня?
Як можна змінити або відобразити дросельну заслінку очищення хмарного рівня?
Чим керує дросельна заслінка очищення хмарного рівня?
Чому хмарне очищення не звільняє/видаляє стільки об'єктів, скільки очікувалося?
Як користувач може визначити, на якому рівні знаходиться файл?
Чи можна прочитати/отримати доступ до файлу безпосередньо після його міграції на рівень хмари?
Скільки файлів можна викликати паралельно?
Як можна викликати файл?
Як можна викликати всі файли в MTree?
Як можна контролювати операцію відкликання?
Чи призводить перейменування файлу до виклику файлу з рівня хмари на активний?
Які хмарні провайдери підтримуються?
Чи підтримується шифрування на рівні хмари та чи має воно бути ліцензованим?
Які сегменти створюються в сховищі об'єктів хмарних провайдерів?
Чи можна використовувати існуючі назви сегментів, які, можливо, були створені раніше?
Крім вимог до обладнання, чи є якісь інші обов'язкові вимоги, які необхідні перед налаштуванням LTR?
Чи потрібні сертифікати і якщо так, то які сертифікати слід використовувати?
Які топології реплікації підтримуються?
Що слід враховувати при налаштуванні/ініціалізації/повторній ініціалізації реплікації в системі, яка вже налаштована LTR?
Що слід враховувати при налаштуванні реплікації MFR/VSR на системі, в якій вже налаштований LTR?
Чому вихід команди «файлова система показує простір» домену даних не відображає фактичний розмір хмарного/об'єктного сховища?
Як можна запустити файлову систему, якщо хмарний блок недоступний?
Якщо хмарний блок вимкнено, як це можна включити?
Чому у файловій системі досі існують файли, які зберігаються на видаленому хмарному пристрої? Чи можна змінити кінцеву точку протоколу або порти для хмарного провайдера ECS або S3 Flexible після створення хмарного блоку?




Що таке LTR?

  • Нова функція під назвою LTR була представлена, починаючи з Data Domain Operating System (DDOS) 6.0.
  • LTR дає змогу певним моделям DDR переносити підмножину файлів або даних на об'єкт або хмарне сховище, відоме як хмарний рівень, від низки підтримуваних постачальників публічних або приватних хмарних послуг.
  • Щоб фізично перенести файли або дані в об'єктне сховище, на DDR запускається процес переміщення даних.
  • Щоб фізично видалити зайві дані з хмарного рівня, на DDR запускається процес очищення хмарного рівня.
  • LTR є ліцензованою функцією і вимагає CLOUDTIER_CAPACITY license.
  • LTR вимагає певного локального сховища для метаданих хмарного рівня.


Для яких систем DDR доступний LTR?
Це залежить від встановленої версії DDOS і типу моделі. Більшість моделей мають певні вимоги до обладнання, які необхідно виконати заздалегідь для налаштування LTR. Ознайомтеся з інсталяцією обладнання для конкретних моделей, а також з посібником з адміністрування DDOS-атак щодо вимог.

Яка ліцензія потрібна для LTR?

  • Оскільки LTR розглядається як нова функція DDOS 6.x і пізніших версій, потрібна електронна ліцензія. 
  • Необхідний тип електронної ліцензії називається CLOUDTIER_CAPACITY license. Приклад CLOUDTIER_CAPACITY license полягає в наступному:
Capacity licenses:
##   Feature              Shelf Model   Capacity     Mode        Expiration Date
--   ------------------   -----------   ----------   ---------   ---------------
1    CLOUDTIER-CAPACITY   n/a           136.42 TiB   permanent   n/a
--   ------------------   -----------   ----------   ---------   ---------------


Як працюють різні рівні?

  • Звичайні DDR (без ліцензії LTR) мають один рівень, відомий як активний рівень.
  • Активний рівень – це традиційний рівень зберігання даних на всіх «стандартних» DDR.
  • Системи LTR мають другий рівень зберігання даних, відомий як хмарний рівень.

Максимальний розмір кожного рівня диктується підтримуваними лімітами для даної конфігурації обладнання та версії DDOS. Зверніться до посібника з адміністрування DDOS та посібника з апаратного забезпечення для конкретної моделі, про яку йдеться.

Приклад дворівневої, однієї активної та однієї хмарної, LTR конфігурації наведено нижче:   

Active Tier:
Resource           Size GiB   Used GiB   Avail GiB   Use%   Cleanable GiB*
----------------   --------   --------   ---------   ----   --------------
/data: pre-comp           -    36674.6           -      -                -
/data: post-comp    65460.3      585.4     64874.8     1%              0.1
/ddvar                 29.5       24.7         3.3    88%                -
/ddvar/core            31.5        1.1        28.8     4%                -
----------------   --------   --------   ---------   ----   --------------

Cloud Tier
Resource           Size GiB   Used GiB   Avail GiB   Use%   Cleanable GiB
----------------   --------   --------   ---------   ----   -------------
/data: pre-comp           -       33.1           -      -               -
/data: post-comp      912.2       42.3       869.9     5%             4.1
----------------   --------   --------   ---------   ----   -------------

Total:
Resource           Size GiB   Used GiB   Avail GiB   Use%   Cleanable GiB
----------------   --------   --------   ---------   ----   -------------
/data: pre-comp           -    36674.6           -      -               -
/data: post-comp    65460.3      585.4     64874.8     1%             0.1
/ddvar                 29.5       24.7         3.3    88%               -
/ddvar/core            31.5        1.1        28.8     4%               -
----------------   --------   --------   ---------   ----   -------------



Як структурований хмарний рівень?

  • Хмарний рівень складається з:   
    • Локально зберігаються метадані, що зберігаються на корпусі, якщо використовується фізичний DDR, або LUN чи пристрій, якщо використовується DDVE.
    • Постачальники об'єктних сховищ
  • І те, і інше об'єднано в хмарну одиницю.
  • Якщо налаштовано кілька хмарних блоків, вони можуть ділитися локально утримуваними метаданими.
  • На одну систему можна налаштувати не більше двох хмарних блоків. Кожен хмарний блок може бути підготовлений від різного постачальника об'єктного сховища.
  • Розмір кожного хмарного блоку може дорівнювати максимальному підтримуваному розміру активного рівня для даної моделі DDR. Зверніться до посібника з адміністрування DDOS для отримання додаткової інформації.


Що відбувається протягом типового життєвого циклу резервного копіювання, коли налаштовано LTR?

  • Усі дані спочатку записуються на активний рівень, де вони починають старіти.
  • Короткотривалі дані, термін зберігання яких закінчується/видаляється, як у звичайному DDR.
  • Однак підмножина даних, які потребують тривалого зберігання, переходить на хмарний рівень.
  • Файлова система підтримує єдиний простір імен на всіх рівнях, тому коли файл мігрує в хмару, простір імен не змінюється і, таким чином, є досить прозорим для користувача або резервної програми.
  • Якщо файл, який уже було перенесено до хмарного рівня, досягає свого терміну зберігання, він втрачає чинність/видаляється, як і будь-який інший файл.
  • Простір, який використовувався файлом на рівні хмари, не звільняється відразу, натомість потрібно запустити очищення хмарного рівня.


Як відбувається дедуплікація даних між рівнями?

  • Кожен хмарний блок є окремим томом, що означає, що він є автономним блоком дедуплікації.
  • Як наслідок, дані, записані в кожен хмарний блок, можуть дедуплікуватися лише з даними в тому самому хмарному пристрої.


Що таке час розміщення (відомий як ptime)?

  • Файли та каталоги мають різні часові позначки, пов'язані з ними.
  • Наприклад, файл або каталог має час створення, час останнього доступу та час модифікації.
  • DDOS ще більше вдосконалив це, включивши в нього час розміщення. Час розміщення – це дата й час, коли файл перейшов з активного рівня на хмарний.
  • Залежно від версії DDOS, час розміщення можна побачити під час перевірки того, на якому рівні знаходиться файл. Якщо файл перейшов на рівень хмари, відображається час розміщення, наприклад:  
sysadmin@dd4500 # filesys report generate file-location
--------------------------------      ---------------------------
File Name                             Location(Unit Name)
--------------------------------      ---------------------------
/data/col1/mtree1/random-data-file-4        cloudunit2           Tue Sep 5 10:17:00 2017
/data/col1/mtree1/random-data-file-5        cloudunit2           Tue Sep 12 15:52:23 2017
/data/col1/mtree1/random-data-file-6        cloudunit2           Tue Sep 13 09:42:55 2017
  • ptime є останнім полем у наведеному вище виведенні, хоча воно не відображає заголовок поля.


Як дані переходять з активного рівня на хмарний?

  • Процес, який називається переміщенням даних, відповідає за перевірку файлів у MTree, які знаходяться на активному рівні.
  • Рух даних починається зі створення знімка всіх MTrees, налаштованих на рух даних.
  • Кожен файл має час зміни, який зберігає час, коли файл було записано востаннє.
  • Якщо файл раніше перенесли на рівень хмари, встановлюється додаткове поле часу, яке називається часом розташування. Час розміщення зберігає дату й час міграції файлу на рівень хмари. Якщо встановлено час розміщення, використовується цей час замість часу модифікації. Це зроблено для того, щоб уникнути постійної міграції файлу назад до хмарного рівня в разі виклику файлу (оскільки виклик файлу не змінює час його модифікації).
  • Знімки, створені вище, обходяться рухом даних.
  • Якщо файл, що перевіряється, досяг визначеного порогового значення, встановленого політикою переміщення даних для відповідного MTree, файл перевіряється, щоб з'ясувати, які дані, що містяться в цьому файлі, повинні мігрувати з активного рівня на хмарний. Політика переміщення даних встановлюється відповідно до MTree.
  • Унікальні сегменти для вибраного файлу записуються або копіюються на рівень хмари. 
  • Після копіювання унікальних сегментів файл перевіряється шляхом їх зчитування, щоб переконатися, що міграція пройшла успішно.
  • Після перевірки файлу метадані оновлюються, щоб відобразити, що тепер файл знаходиться на рівні хмари.
  • Процес переміщення даних може виконуватися з певною частотою або ініціюватися вручну.


Коли починається рух даних, які фази є і які дії виконує кожна фаза?

  • Існує три фази, пов'язані з переміщенням даних: фаза копіювання, фаза перевірки та фаза встановлення.
  • Етап копіювання відповідає за визначення сегментів, які потрібно скопіювати в хмару, а потім міграцію цих сегментів у хмару.
  • Як тільки починається фаза копіювання, вона є хмарним або об'єктним сховищем і використовується як фаза копіювання копіює сегменти, визначені з активного рівня на рівень хмари.
  • Етап перевірки відповідає за те, щоб сегменти файлу були успішно перенесені в хмару.
  • Фаза встановлення відповідає за оновлення метаданих, що стосуються файлу, який був перенесений, щоб показати, що вони тепер знаходяться в хмарному або об'єктному сховищі.
  • Кожен файл повинен пройти всі три фази, щоб переміщення даних було визнано успішним для цього файлу. Таким чином, поки не завершиться етап інсталяції файлу, файл залишається на активному рівні.


Які політики переміщення даних доступні?

  • Політика переміщення даних може бути однією з наведених нижче.   
    • Віковий поріг: Якщо час розміщення або зміни файлів перевищує встановлений віковий діапазон, він вибирається для міграції на хмарний рівень.
    • Віковий діапазон: Якщо час розміщення або модифікації файлу потрапляє в певний діапазон, він вибирається для міграції на рівень хмари.
    • Визначення сфери застосування: Програма резервного копіювання визначає, чи потрібно вибрати файл для міграції на рівень хмари.
  • Політики є взаємовиключними, тобто MTree може мати лише одну встановлену політику одночасно.


Як можна встановити політику переміщення даних на MTree?

  • Можна використовувати наведену нижче команду. Наприклад:   
data-movement policy set <policy name> <policy type values> totier cloud cloud-unit <cloud unit name> mtrees <mtree list>

sysadmin@dd4500 # data-movement policy set age-threshold 14 to-tier cloud cloud-unit cloudunit1 mtrees /data/col1/mtree1
sysadmin@dd4500 # data-movement policy set age-range min-age 14 max-age 100 to-tier cloud cloud-unit cloudunit1 mtrees /data/col1/mtree1
sysadmin@dd4500 # data-movement policy set app-managed to-tier cloud cloud-unit cloudunit1 mtrees /data/col1/mtree1


    Які політики переміщення даних вже налаштовані?

    • Наведена нижче команда надає список того, яким MTrees призначено будь-які політики переміщення даних. Наприклад:   
    data-movement policy show
    
    sysadmin@dd4500 # data-movement policy show
    Mtree               Target(Tier/Unit Name)   Policy      Value      
    -----------------   ----------------------   ---------   -----------
    /data/col1/mtree1   Cloud/cloudunit1         age-range   14-100 days
    -----------------   ----------------------   ---------   -----------


    Як працює політика переміщення даних, керована додатком?

    • Політика переміщення даних для відповідного MTree встановлена на керовану програмою. Це або робиться вручну, або програма для резервного копіювання виконує це за допомогою інтерфейсу Data Domain REST API.
    • Програма резервного копіювання має бути обізнана з LTR.
    • Програма резервного копіювання має використовувати DD Boost, а версія DD Boost має бути сумісною з LTR і сумісною.
    • Використовуючи бібліотеку/API DD Boost, програма резервного копіювання встановить час розміщення файлу, який необхідно перенести на рівень хмари, на спеціальне значення, яке вказує, що наступного разу, коли почнеться переміщення даних, файл підлягає міграції в хмару.
    • Коли рух даних виконується в системі Data Domain, перевіряється час розміщення і якщо встановлено спеціальне значення, як було сказано вище, то він переносить файл у хмару.


    Як можна запустити переміщення даних вручну?

    • Можна використовувати наведену нижче команду, наприклад:   
    data-movement start
    
    sysadmin@dd4500 # data-movement start
    Data-movement started.


    Як можна відстежувати рух даних?

    • Наведену нижче команду можна використовувати для перевірки статусу переміщення даних. Наприклад:   
    data-movement status
    
    sysadmin@dd4500 # data-movement status
    Data-movement to cloud tier:
    ----------------------------
    Data-movement is initializing..
    
    Data-movement recall:
    ---------------------
    No recall operations found. 
    • Якщо виконується переміщення даних, можна використовувати наведену нижче команду, наприклад:   
    data-movement watch 
    
    sysadmin@dd4500 # data-movement watch
    Data-movement: phase 1 of 3 (copying)
       92% complete; time: phase  0:08:04, total  0:08:14
          Copied (post-comp): 3.35 GiB, (pre-comp): 3.29 GiB,B,
          Files copied: 7, Files verified: 3, Files installed: 3


    Як можна зупинити рух даних?

    • Можна використовувати наведену нижче команду. Наприклад:   
    data-movement stop 
    
    sysadmin@dd4500 # data-movement stop
    Data-movement stop initiated. Run the status command to check its status.


    Якщо хмарних блоків більше, ніж одиниця, чи може переміщення даних здійснюватися до обох хмарних блоків одночасно?

    • Ні. По суті, рух даних може переносити дані лише на один хмарний блок за раз.


    Як налаштовується LTR?

    • Це огляд високого рівня, дивіться детальний процес у посібнику з адміністрування DDOS.
    • Додайте відповідний CLOUDTIER_CAPACITY license.
    • Встановіть парольну фразу системи, якщо її ще не встановлено.
    • Увімкніть функцію хмарного сховища.
    • Додайте сховище метаданих для хмарного рівня.
    • Налаштуйте хмарний профіль або профіль для відповідного постачальника хмарних або об'єктних сховищ.
    • Додайте хмарну одиницю.
    • Налаштуйте політику переміщення даних для MTree або MTrees, які вимагають зберігання даних у хмарі.
    • Запустіть переміщення даних вручну або дочекайтеся початку автоматичного чи запланованого переміщення даних.


    Чи можна видалити хмарний блок? Якщо так, то яким чином?

    • Обережність: Це знищує будь-які дані, що зберігаються на хмарному пристрої, отже, дані неможливо відновити, тому дійте обережно.
    • Перегляньте розділ цього документа бази знань під назвою «Як користувач може визначити, на якому рівні розташований файл», щоб зрозуміти, які файли зберігаються на хмарному пристрої, який потрібно видалити.
    • Ці файли слід або видалити, якщо вони більше не потрібні, або відкликати до активного рівня, якщо їх потрібно зберегти.
    • Якщо файли потрібно зберегти, переконайтеся, що всі файли викликані, перш ніж продовжити.
    • На хмарному блоці не повинно залишитися файлів, які видаляються.
    • Скиньте будь-які політики переміщення даних для MTree або MTrees, які використовують цей хмарний блок.
    • Вимкніть файлову систему.
    • Видаліть хмарний блок. Це позначає хмарний блок у стані DELETE_PENDING, який відповідає дизайну.
    • Увімкніть файлову систему.
    • Після запуску файлової системи вона асинхронно починає видаляти всі об'єкти в хмарі або постачальнику об'єктного сховища, які використовувалися цим хмарним блоком. Після видалення всіх об'єктів видаляються і сегменти, які використовував цей хмарний блок. Якщо об'єктів багато, то хмарний блок може перебувати в стані DELETE_PENDING протягом тривалого часу.
    • Після успішного видалення всіх об'єктів і сегментів хмарний блок зникає зі списку хмарних блоків.


    Що станеться, якщо хмарний блок не вдасться видалити через те, що об'єктне сховище більше не доступне або виникла проблема з підключенням?


    Чи можна налаштувати LTR і розширене зберігання (ER) в одній системі?

    • Ні. ER і LTR є взаємовиключними функціями.


    Як відбувається звільнення або очищення даних із хмарного рівня?

    • Це працює подібно до файлів, що знаходяться на активному рівні
    • Як тільки файл досягає свого терміну зберігання, він видаляється з простору імен файлової системи.
    • За розкладом заплановано очищення хмарного рівня. За замовчуванням хмарне очищення виконується після кожних чотирьох активних сеансів очищення рівня.
    • Щоб очищення хмарного рівня працювало, хмарний блок, який очищається, повинен мати принаймні 1% зайвих або очищених даних, щоб розпочати роботу. Це пов'язано з тим, що будь-який трафік хмарної мережі може бути платним, тому DDR намагається обмежити мережевий трафік, де це можливо.
    • Хмарний рівень працює з дросельною заслінкою очищення за замовчуванням 50%.
    • Можна змінити як графік очищення хмарного рівня, так і дросельну заслінку очищення.
    • Активне очищення рівнів і хмар не може виконуватися паралельно.
    • Якщо виконується автоматичне або заплановане хмарне прибирання, воно має пріоритет перед активним прибиранням рівня очищення.
    • Якщо ініційовано очищення рівня хмари вручну, активне очищення рівня не може розпочатися, доки не буде завершено очищення рівня хмари.
    • Якщо хмарний рівень має два хмарні блоки, на один запланований або автоматичний рівень очищення хмари очищається лише один хмарний блок. Хмарні блоки працюють за круговою системою з точки зору очищення хмарних рівнів. Якщо хмарних блоків два, обов'язковим є визначення хмарного блоку для очищення під час запуску з командного рядка (назва> початкового <блоку cloud clean)
    • Наприклад, якщо хмарне очищення не запускається на хмарному блоці, наприклад, поточний хмарний блок не має достатньо даних, які можна очистити, щоб вважати його вартим уваги, тоді система автоматично спробує очистити його з наступного хмарного блоку.
    • Щоб дізнатися більше про очищення хмарного рівня, перегляньте наступну статтю Домен даних: Вступ до довгострокового зберігання, очищення хмарного рівня та збору сміття на платформах відновлення доменів даних (DDR)


    Як починається чистота ручного хмарного рівня?

    • Можна використовувати наведену нижче команду. Наприклад:   
    cloud clean start <cloud unit> 
    
    sysadmin@dd4500 # cloud clean start cloudunit2
    Cloud tier cleaning started for cloud unit "cloudunit2". Use 'cloud clean watch' to monitor progress.


    Як можна контролювати очищення хмарного рівня?

    • Наведену нижче команду можна використовувати, щоб перевірити, чи виконується хмарне очищення. Наприклад:   
    cloud clean start <cloud unit> 
    
    sysadmin@dd4500 # cloud clean status
    Previous cloud tier cleaning attempt was unsuccessful.
     Failure reason:
    cloud unit "cloudunit2" did not have sufficient cleanable data.
    Cloud tier cleaning finished at 2017/03/15 12:16:06.
    • Якщо хмарне очищення запущено, його можна відстежувати за допомогою наведеної нижче команди:
    cloud clean watch


    Чи може активне багаторівневе прибирання виконуватися одночасно з прибиранням хмарного рівня?

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


    Як можна відобразити або змінити графік прибирання хмарного рівня?

    • Наведену нижче команду можна використовувати для відображення поточного графіка очищення хмари. Наприклад:   
    cloud clean frequency show
    
    sysadmin@dd4500 # cloud clean frequency show
    Cloud tier cleaning frequency is set to run after every 4 active tier cleaning cycles.
    • Наведена нижче команда використовується для зміни розкладу. Наприклад:  
    cloud clean frequency set <value>
    
    sysadmin@dd4500 # cloud clean frequency set 3
    Cloud tier cleaning frequency is set to run after every 3 active tier cleaning cycles.
    


    Як можна змінити або відобразити дросельну заслінку очищення рівня хмари?

    • За замовчуванням дросельна заслінка хмарного рівня очищення встановлена на 50%. Наведену нижче команду можна використовувати для скидання його до стандартного відсотка дросельної заслінки.
    cloud clean throttle reset
    • Наведену нижче команду можна використовувати для відображення поточної дросельної заслінки очищення хмари. Наприклад:   
    cloud clean throttle show
    
    sysadmin@dd4500 # cloud clean throttle show
    Cloud tier cleaning throttle is set to 28 percent
    • Наведену нижче команду можна використовувати для зміни дросельної заслінки очищення. Наприклад:   
    cloud clean throttle set <value> 
    
    sysadmin@dd4500 # cloud clean throttle set 20
    Cloud tier cleaning throttle set to 20 percent


    Чим керує дросельна заслінка з очищенням рівня хмари?

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


    Чому хмарне очищення не звільняє/видаляє стільки об'єктів, скільки очікувалося?

    • Прибирання завжди вважається кошторисом. Перегляньте наведені нижче статті бази знань, у яких описано аспекти, пов'язані з цією темою, оскільки вони однаково стосуються даних, що знаходяться на рівні хмари:  
    Лише зареєстровані клієнти Dell можуть отримати доступ до вмісту за наступним посиланням, використовуючи службу підтримки Dell, Data Domain: Розмір, який можна очистити, є приблизним.
    • Крім того, є додаткові конкретні деталі, пов'язані з тим, як реалізовано хмарний рівень.
    • Були впроваджені різні методи для обмеження обсягу мережевого трафіку для постачальника хмарного або об'єктного сховища, оскільки це може супроводжуватися пов'язаними з цим витратами.
    • Як згадувалося вище, для чистого виконання потрібно мінімум 1% відтоку даних.
    • Коли файлова система обходить файлову систему для пошуку файлів, які відповідають політиці переміщення даних, перевіряються лише локальні копії метаданих.
    • Будь-які сегменти, що зберігаються в хмарному або об'єктному сховищі, які містять лише дані користувача, позначаються для асинхронного видалення.
    • Будь-які сегменти, що містять хоча б один сегмент в реальному часі, пропускаються, оскільки DDOS не хоче об'єднувати невеликі обсяги даних через задіяний мережевий трафік.


    Як користувач може визначити, на якому рівні знаходиться файл?

    • Використовуйте наведену нижче команду для прикладу виведення, згенерованого цією командою:  
    filesys report generate file-location
    
    sysadmin@dd4500 # filesys report generate file-location
    --------------------------------      ---------------------------
    File Name                             Location(Unit Name)
    --------------------------------      ---------------------------
    /data/col1/mtree1/random-data-file-1        Active
    /data/col1/mtree1/random-data-file-2        Active
    /data/col1/mtree1/random-data-file-4        cloudunit2
    /data/col1/mtree1/random-data-file-5        cloudunit2
    /data/col1/mtree1/random-data-file-6        cloudunit2


    Чи можна прочитати файл або отримати доступ до нього одразу після його міграції на рівень хмари?

    • Це залежить від версії DDOS-атак, яка використовується та постачальника хмарних послуг:   
    З DDOS 6.1 та з використанням ECS:
    • Безпосереднє відновлення файлів можливе без попереднього виклику файлу. Ця функція відома як функція «прямого відновлення» і обмежується ECS як постачальником хмари або об'єктів.
    • Щоб дізнатися більше про «пряме відновлення» від Avamar, перегляньте офіційний документ «Avamar Granular або File Level Restore from Data Domain Cloud Tier».
    • Функція Avamar GLR/FLR (пряме відновлення) потребує мінімальної комбінації Avamar 18.1 або DDOS 6.1 з ECS як постачальником хмарних послуг. 
    Інакше:   
    • Спочатку файл потрібно відкликати. Тобто дані мігрували назад з хмарного рівня на активний.
    • Файл має бути викликаний з рівня хмари на активний за допомогою команди виклику переміщення даних, щоб дозволити будь-яке читання з файлу або внесення змін до файлу, який знаходиться на рівні хмари.
    • Будь-яка спроба прочитати або змінити файл, який знаходиться на рівні хмари, призводить до того, що помилка вводу/виводу повертається до того, хто намагається прочитати файл, який є програмою резервного копіювання, якщо файл не викликається першим.
    • Деякі програми резервного копіювання з урахуванням хмари можуть ініціювати відкликання файлів, інакше файли потрібно викликати вручну.
    • Починаючи з DDOS 7.7+:
      • Пряме відновлення дає змогу неінтегрованим програмам читати файли безпосередньо з хмарного рівня, не переходячи через активний рівень.
      • Ключові міркування при виборі використання прямого відновлення включають:
      • Пряме відновлення не вимагає інтегрованої програми та є прозорим для неінтегрованих програм.
      • Для читання з хмарного рівня не потрібно спочатку копіювати в активний рівень.
      • Гістограми та статистика доступні для відстеження прямого зчитування з хмарного рівня.
      • Пряме відновлення підтримується лише для хмарних провайдерів AWS та ECS .
      • Застосунки мають затримку на хмарному рівні.
      • Читання безпосередньо з хмарного рівня не оптимізовано пропускну здатність.

    Скільки файлів можна викликати паралельно?

    • DDOS 6.0 підтримує чотири файли для паралельного встановлення в чергу та виклику.
    • DDOS 6.1 підтримує 1000 файлів для черги та 4 файли в черзі виклику для паралельного виклику.

    Відповідно до Посібника з адміністрування домену даних 7.9:

    • Системи з 256 ГБ пам'яті і більше можуть викликати до 16 файлів за один раз.
    • Системи з пам'яттю менше 256 ГБ можуть викликати до восьми файлів за один раз.
    • Екземпляри DDVE можуть викликати до чотирьох файлів одночасно.


    Як можна викликати файл?

    • Файл можна викликати за допомогою наведеної нижче команди. Наприклад:   
    data-movement recall path <path-name> 
    
    sysadmin@dd4500 # data-movement recall path /data/col1/mtree1/file1


    Як можна викликати всі файли в MTree?

    • Залежно від версії DDOS, усі файли в Cloud можуть бути викликані виконанням однієї команди, наприклад, нижче:   
    sysadmin@dd4500 # data-movement recall mtree /data/col1/mtree1
    • Щоб дізнатися більше, перегляньте «Довідковий посібник із команд Dell DDOS» для вашої версії DDOS


    Як можна контролювати операцію відкликання?

    • Операцію з виклику можна контролювати за допомогою наведеної нижче команди або якщо потрібен певний файл. Наприклад:   
    data-movement status path all
    
    data-movement status path /data/col1/mtree/file1
    
    sysadmin@dd4500 # data-movement status path /data/col1/mtree1/file1
    Data-movement recall:
    ---------------------
    Data-movement for  /data/col1/mtree1/file1 : phase 2 of 3
    (Verifying)
    80% complete; time: phase XX:XX:XX total XX:XX:XX
    Copied (post-comp): XX XX, (pre-comp) XX XX 


    Чи призводить перейменування файлу до виклику файлу з рівня хмари на активний?

    • Ні. Якщо файл перейменовано, він залишається на поточному рівні.


    Які хмарні провайдери підтримуються?

    •  Залежно від використовуваної версії DDOS, DDOS підтримує таких постачальників хмарних послуг:   
    • Веб-сервіси Amazon (AWS).
    • Microsoft Azure Cloud
    • Хмарне сховище Dell Elastic (ECS)
    • Virtustream
    • Зверніться до посібника з адміністрування DDOS для отримання додаткової інформації.


    Чи підтримується шифрування на рівні хмари та чи потрібно його ліцензувати?

    • Так, шифрування підтримується на рівні хмари. Для цього не потрібна додаткова ліцензія, на відміну від шифрування активного рівня.
    • Це можна налаштувати, коли хмарну функцію ввімкнено або змінено після. 
    • На момент написання цієї статті для шифрування хмарного рівня підтримується лише менеджер вбудованих ключів, а для всієї системи LTR можна використовувати лише один алгоритм шифрування.


    Які сегменти створюються в сховищі об'єктів хмарних провайдерів?

    • DDOS створює три сегменти
    • Відра закінчуються мотузкою:
    '-d0'
    
    '-c0' 
    
    '-m0'
    • Сегмент, який закінчується рядком '-d0', використовується для сегментів даних.
    • Сегмент, який закінчується рядком '-c0', використовується для даних конфігурації.
    • Сегмент, який закінчується рядком '-m0', використовується для метаданих.
    • До DDOS 6.1, коли створюється три сегменти, використовується лише кінець сегмента '-d0'. Однак всі три відра потрібні, тому стежте за тим, щоб їх не прибирали.


    Чи можна використовувати наявні назви сегментів, які були створені раніше?

    • Ні, це неможливо.


    Крім вимог до обладнання, чи є якісь інші обов'язкові вимоги, які необхідні перед налаштуванням LTR?

    • Так
    • Якщо використовується ECS, балансувальник навантаження є обов'язковою вимогою. Без балансувальника навантаження Data Domain обмінюється даними з ECS на одному вузлі та відключається, коли надходить кілька запитів.
    • Мережа об'ємом 1 Гб між DDR і хмарним провайдером


    Чи потрібні сертифікати і якщо так, то які сертифікати слід використовувати?

    • Це залежить від об'єкта або постачальника хмари, який використовується, а також від конфігурації.
    • Для AWS, Virtustream або Azure потрібен сертифікат. Зверніться до посібника з адміністрування DDOS для отримання додаткової інформації.
    • Якщо ECS налаштовано за допомогою кінцевої точки http, сертифікат не потрібен.
    • Якщо ECS налаштовано за допомогою кінцевої точки https, потрібен сертифікат. Оскільки балансувальник навантаження є обов'язковою вимогою, необхідний сертифікат із системи балансування кредитів, а не з системи ECS. Зверніться до свого постачальника розподілювача навантаження для отримання додаткової інформації.
    • При імпорті сертифіката він повинен бути у форматі PEM. Деякі постачальники не надають сертифікат у форматі PEM, тому його потрібно конвертувати перед імпортом.


    Які топології реплікації підтримуються?

    • Реплікація колекції _не_ підтримується.
    • Підтримується реплікація каталогів, однак вона може використовуватися лише MTree '/data/col1/backup', але цей MTree не підтримує переміщення даних.
    • Повністю підтримується реплікація MTree.
    • Повністю підтримується реплікація MFR або VSR.


    Що слід враховувати при налаштуванні/ініціалізації/повторній ініціалізації реплікації в системі, яка вже налаштована LTR?

    • Система вихідного коду робить знімок MTree (цей знімок включає деталі файлів на активному та хмарному рівнях).
    • Система джерел реплікує знімок на активний рівень системи призначення.
    • Лише коли знімок повністю репліковано, він відображається в системі призначення (після чого файли стають доступними в просторі імен файлової системи системи призначення).
    • Лише після того, як файли будуть розкриті, можна запустити рух даних до місця призначення (за умови, що він налаштований на LTR).
    • В результаті, якщо активний рівень призначення недостатньо великий, щоб вмістити повний знімок з джерела, знімок ніколи не відкривається, і реплікація не може завершити ініціалізацію.


    Що потрібно враховувати при налаштуванні реплікації MFR або VSR на системі, в якій вже налаштований LTR?

    • Якщо дані, які вже були перенесені на хмарний рівень на джерельному DDR, повинні бути репліковані, вони автоматично викликаються від постачальника хмари до активного рівня, перш ніж їх можна буде надіслати через мережу.
    • Виклик файлів із хмарного рівня на активний може спричинити витрати або затримку.


    Чому вихідні дані команди «файлова система показує простір» не відображають справжній розмір хмари або об'єктного сховища?

    • Через властивий спосіб роботи хмари або об'єктного сховища, система Data Domain не має можливості запитувати фізичний розмір хмарного пристрою, оскільки це може розглядатися як здавалося б, нескінченне.
    • Однак DDOS довелося розробити спосіб відображення поточної статистики використання/дедуплікації з точки зору DDOS.
    • Тому використовується один з двох підходів:
    1. Розмір хмарного рівня визначається CLOUDTIER_CAPACITY license
    2. Розмір рівня хмари відображається як кратний розмірам активних модулів для цього типу моделі залежно від того, скільки хмарних блоків налаштовано. Перегляньте інсталяцію обладнання для відповідної моделі для отримання додаткової інформації щодо розмірів активних рівнів.


    Як можна запустити файлову систему, якщо хмарний блок недоступний?

    • Переконайтеся, що файлова система вимкнена.
    • Вимкніть хмарний блок, який недоступний, за допомогою наведеної нижче команди:
    cloud unit disable <cloud unit name>
    • Увімкніть файлову систему.


    Якщо хмарний блок вимкнено, як це можна включити?

    • Переконайтеся, що файлова система вимкнена.
    • Увімкніть хмарний блок за допомогою наведеної нижче команди:
    cloud unit enable <cloud unit name>
    • Увімкніть файлову систему.


    Чому у файловій системі досі існують файли, які зберігаються на видаленому хмарному пристрої?

    •  Якщо файли не були видалені з MTree до видалення хмарного блоку, файли продовжують існувати в просторі імен файлових систем.
    • Таким чином, звіт про розташування файлу показує, що файли є частиною видаленого хмарного блоку. Наприклад:  
    sysadmin@dd4500 # filesys report generate file-location
    --------------------------------      ---------------------------
    File Name                             Location(Unit Name)
    --------------------------------      ---------------------------
    /data/col1/mtree1/random-data-file-3  Deleted cloud-unit
    /data/col1/mtree1/random-data-file-4  Deleted cloud-unit
    
    • Файли все ще можна побачити в просторі імен файлової системи, отримавши доступ до спільного ресурсу CIFS/NFS для цього MTree.
    • Однак файли не читаються, оскільки хмарний блок, де вони знаходилися, було видалено.
    • Тому єдиним варіантом є видалення цих файлів, оскільки їхні дані, на які вони посилалися, більше не існують.


    Чи можна змінити кінцеву точку протоколу або порти для хмарного провайдера ECS або S3 Flexible після створення хмарного блоку?

    • Наприклад, це може знадобитися при переході з http на https або, навпаки, міграції на новий розподілювач навантаження.
    • На момент написання цієї статті адміністратор домену даних не може виконати цю зміну. Ця функція розглядається для майбутнього випуску DDOS-атак.
    • Однак це може бути виконано за допомогою підтримки або інженерії.
    • Файлова система має бути вимкнена, щоб виконати цю зміну.
    • Якщо це потрібно, спочатку виконується вся конфігурація за межами системи Data Domain, оскільки як тільки це зміниться, коли файлова система увімкнена, вона зможе обмінюватися даними за допомогою оновленого протоколу або порту та читати сегменти або об'єкти, як це було раніше.

    Affected Products

    Data Domain

    Products

    Data Domain, DD OS
    Article Properties
    Article Number: 000023144
    Article Type: How To
    Last Modified: 14 Oct 2025
    Version:  13
    Find answers to your questions from other Dell users
    Support Services
    Check if your device is covered by Support Services.