Data Domain Restorer i retencja długoterminowa w chmurze: Najczęściej zadawane pytania

Ten artykuł zawiera odpowiedzi na najczęściej zadawane pytania dotyczące konfiguracji i korzystania z systemów Data Domain Restorer (DDR) oraz funkcji Long-Term Retention (LTR) lub funkcji chmury.
 

Co to jest LTR?

• Nowa funkcja o nazwie LTR została wprowadzona począwszy od Data Domain Operating System (DDOS) 6.0.
• LTR umożliwia niektórym modelom DDR migrację podzbioru plików lub danych do obiektowej pamięci masowej lub pamięci masowej w chmurze, tzw. warstwy chmury, od wielu obsługiwanych dostawców publicznych lub prywatnych rozwiązań chmurowych.
• Aby przeprowadzić fizyczną migrację plików lub danych do obiektowej pamięci masowej, w systemie DDR zostaje uruchomiony proces przenoszenia danych.
• Aby fizycznie zwolnić nadmiarowe dane z warstwy chmury, w systemie DDR zostaje uruchomiony proces czyszczenia warstwy chmury.
• LTR jest funkcją licencjonowaną i wymaga CLOUDTIER_CAPACITY license.
• LTR wymaga pewnej ilości lokalnej pamięci masowej dla metadanych warstwy chmury.

Do jakich systemów DDR jest dostępna funkcja LTR?
Zależy to od zainstalowanej wersji systemu DDOS oraz typu modelu systemu. Większość modeli ma pewne wymagania sprzętowe, które muszą być spełnione z wyprzedzeniem, aby można było skonfigurować LTR. Szczegółowe informacje na temat wymagań można znaleźć w podręczniku instalacji sprzętu dla określonych modeli oraz podręczniku administracji DDOS.

Jaka licencja jest wymagana dla LTR?

• Ponieważ LTR jest uważany za nową funkcję w DDOS 6.x i nowszych, wymagana jest e-licencja. 
• Wymagany rodzaj e-licencji nazywa się CLOUDTIER_CAPACITY license. Przykładem CLOUDTIER_CAPACITY license jest:

Capacity licenses:
##   Feature              Shelf Model   Capacity     Mode        Expiration Date
--   ------------------   -----------   ----------   ---------   ---------------
1    CLOUDTIER-CAPACITY   n/a           136.42 TiB   permanent   n/a
--   ------------------   -----------   ----------   ---------   ---------------

Jak działają poszczególne poziomy?

• Zwykłe systemy DDR (bez licencji LTR) mają jedną warstwę zwaną warstwą aktywną.
• Warstwa aktywna to tradycyjna warstwa pamięci masowej we wszystkich „standardowych” systemach DDR.
• Systemy z LTR mają drugą warstwę pamięci masowej, nazywaną warstwą chmury.

Maksymalny rozmiar każdej warstwy jest podyktowany obsługiwanymi limitami dla danej konfiguracji sprzętu i wersji DDOS. Zapoznaj się z podręcznikiem administracyjnym DDOS i przewodnikiem sprzętowym dla danego modelu.

Przykład dwuwarstwowej konfiguracji LTR, z jedną warstwą aktywną i jedną warstwą chmurową, pokazano poniżej:   

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%               -
----------------   --------   --------   ---------   ----   -------------

Jaka jest struktura warstwy chmury?

• W skład warstwy chmurowej wchodzą:   
  • Lokalnie przechowywane metadane przechowywane w obudowie, jeśli stosowane jest fizyczne rozwiązanie DDR, albo w jednostce LUN lub urządzeniu, jeśli stosowane jest rozwiązanie DDVE.
  • Dostawcy obiektowych pamięci masowych
• Oba powyższe elementy są połączone w jednostkę chmury.
• Jeśli skonfigurowano wiele jednostek chmury, mogą one współużytkować lokalnie przechowywane metadane.
• W każdym systemie można skonfigurować maksymalnie dwie jednostki chmury. Każda jednostka chmury może pochodzić od innego dostawcy obiektowej pamięci masowej.
• Każda jednostka chmury może być tak duża jak maksymalny obsługiwany rozmiar aktywnej warstwy dla danego modelu DDR. Więcej informacji można znaleźć w podręczniku administratora DDOS.

Co się dzieje podczas typowego cyklu życia kopii zapasowej po skonfigurowaniu LTR?

• Wszystkie dane są początkowo zapisywane w warstwie aktywnej, w której zaczynają się starzeć.
• Dane o krótkim terminie przechowywania, które osiągnęły okres retencji, wygasają/są usuwane tak jak w normalnym systemie DDR.
• Jednak podzbiór danych wymagających długoterminowego przechowywania jest migrowany do warstwy chmury.
• System plików utrzymuje jedną przestrzeń nazw we wszystkich warstwach, więc gdy plik jest migrowany do chmury, przestrzeń nazw nie zmienia się i jako taka jest dość przejrzysta dla użytkownika lub aplikacji do tworzenia kopii zapasowych.
• Plik, który został już przeniesiony do warstwy chmury, wygasa/zostaje usunięty tak samo jak każdy inny plik.
• Miejsce, z którego plik korzystał w warstwie chmury, nie jest odzyskiwane natychmiast, ale należy uruchomić czyszczenie warstwy chmury.

Jak przebiega deduplikowanie danych między poziomami?

• Każda jednostka chmury jest autonomicznym woluminem, co oznacza, że jest to samodzielna jednostka deduplikacji.
• W związku z tym dane zapisane w każdej jednostce chmury mogą być deduplikowane tylko na podstawie danych w tej samej jednostce chmury.

Co to jest czas umieszczenia (znany jako ptime)?

• Pliki i katalogi mają skojarzone różne sygnatury czasowe.
• Na przykład plik lub katalog ma czas utworzenia, czas ostatniego dostępu i czas modyfikacji.
• W systemie DDOS ten zakres jest jeszcze szerszy i uwzględnia również czas umieszczenia. Czas umieszczenia to data i godzina migracji pliku z warstwy aktywnej do warstwy chmury.
• W zależności od wersji systemu DDOS czas umieszczenia można zobaczyć podczas sprawdzania, w której warstwie znajduje się plik. Jeśli plik został przeniesiony do warstwy chmury, wyświetlany jest czas umieszczenia, na przykład:  

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 to ostatnie pole w powyższych danych wyjściowych, chociaż nie ma nagłówka pola.

Jak dane są przenoszone z warstwy aktywnej do warstwy chmury?

• Proces nazywany przenoszeniem danych jest odpowiedzialny za badanie plików w MTree, które znajdują się w warstwie aktywnej.
• Przenoszenie danych rozpoczyna się od utworzenia migawki wszystkich drzew MTree skonfigurowanych do przenoszenia danych.
• Każdy plik ma czas modyfikacji, który jest czasem ostatniego zapisu pliku.
• Jeśli plik został wcześniej przeniesiony do warstwy chmury, dodawane jest pole czasu zwanego czasem umieszczenia. Czas umieszczenia wskazuje datę i godzinę migracji pliku do warstwy chmury. Jeżeli istnieje czas umieszczenia, jest on używany zamiast czasu modyfikacji. Ma to na celu uniknięcie ciągłego migrowania pliku z powrotem do warstwy chmury, jeśli plik zostanie odwołany (ponieważ odwołanie pliku nie zmienia czasu jego modyfikacji).
• Utworzone powyżej migawki są przesuwane przez proces przenoszenia danych.
• Jeśli badany plik osiągnął zdefiniowaną wartość progową określoną przez zasady przenoszenia danych dla stosownego drzewa MTree, jest on sprawdzany w celu ustalenia, jakie dane przechowywane w tym pliku muszą zostać przeniesione z warstwy aktywnej do warstwy chmury. Zasady przenoszenia danych są ustawiane dla każdego drzewa MTree.
• Niepowtarzalne segmenty dla wybranego pliku są zapisywane lub kopiowane do warstwy chmury. 
• Po skopiowaniu niepowtarzalnych segmentów zostają one odczytane w celu zweryfikowania pliku, co ma potwierdzić, że migracja zakończyła się pomyślnie.
• Po zweryfikowaniu pliku metadane zostają zaktualizowane w celu odzwierciedlenia faktu, że plik znajduje się teraz w warstwie chmury.
• Proces przenoszenia danych można zaplanować tak, aby był uruchamiany z określoną częstotliwością lub można go zainicjować ręcznie.

Kiedy rozpoczyna się przenoszenie danych, jakie są fazy i jakie akcje są realizowane w każdej fazie?

• Istnieją trzy fazy związane z przenoszeniem danych: faza kopiowania, faza weryfikacji i faza instalacji.
• Faza kopiowania jest odpowiedzialna za identyfikację segmentów, które należy skopiować do chmury, a następnie migrację tych segmentów do chmury.
• Gdy ta faza się rozpocznie, do kopiowania zidentyfikowanych segmentów z warstwy aktywnej do warstwy chmury jest wykorzystywana pamięć masowa w chmurze lub obiektowa pamięć masowa.
• Faza weryfikacji odpowiada za sprawdzenie, czy segmenty pliku zostały pomyślnie przeniesione do chmury.
• Faza instalacji odpowiada za aktualizację metadanych dotyczących przeniesionego pliku, aby wskazywały, że plik znajduje się teraz w pamięci masowej w chmurze lub w obiektowej pamięci masowej.
• Każdy plik musi przejść wszystkie trzy fazy, aby przenoszenie danych zostało uznane za pomyślne dla tego pliku. W związku z tym do momentu zakończenia fazy instalacji plik pozostaje w warstwie aktywnej.

Jakie zasady przenoszenia danych są dostępne?

• Zasady przenoszenia danych mogą być następujące:   
  • Próg wiekowy: Jeśli czas umieszczenia lub modyfikowania pliku przekracza ustawiony zakres wiekowy, jest on wybierany do migracji do warstwy chmury.
  • Przedział wiekowy: Jeśli czas umieszczenia lub modyfikacji pliku mieści się w określonym zakresie, jest on wybierany do migracji do warstwy chmury.
  • Zdefiniowane przez aplikację: Aplikacja do tworzenia kopii zapasowych określa, czy plik ma zostać wybrany do migracji do warstwy chmury.
• Zasady wzajemnie się wykluczają, co oznacza, że drzewo MTree może mieć ustawione tylko jedne zasady na raz.

W jaki sposób można ustawić zasady przenoszenia danych w MTree?

• Można użyć poniższego polecenia. Na przykład:   

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

Jakie zasady przenoszenia danych są już skonfigurowane?

• Poniższe polecenie zapewnia listę drzew MTree, do których przypisano jakieś zasady przenoszenia danych. Na przykład:   

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
-----------------   ----------------------   ---------   -----------

Jak działają zasady przenoszenia danych zarządzane przez aplikację?

• Zasady przenoszenia danych dla danego drzewa MTree muszą być ustawione na „zarządzane przez aplikację”. Robi się to ręcznie albo aplikacja do tworzenia kopii zapasowych wykonuje to za pomocą interfejsu API REST Data Domain.
• Aplikacja do tworzenia kopii zapasowych musi obsługiwać LTR.
• Aplikacja do tworzenia kopii zapasowych musi korzystać z DD Boost, a wersja DD Boost musi obsługiwać LTR i być zgodna.
• Korzystając z biblioteki/interfejsu API DD Boost, aplikacja do tworzenia kopii zapasowych ustawi czas umieszczania pliku, który musi zostać zmigrowany do warstwy chmury, jest ustawiony na specjalną wartość wskazującą, że następnym razem, gdy zostanie uruchomione przenoszenie danych, plik ma zostać zmigrowany do chmury.
• Po uruchomieniu przenoszenia danych w systemie Data Domain następuje sprawdzenie czas umieszczenia i jeśli jest on ustawiony na specjalną wartość, jak wspomniano powyżej, plik jest przenoszony do chmury.

Jak ręcznie uruchomić przenoszenie danych?

• Można użyć poniższego polecenia, na przykład:   

data-movement start

sysadmin@dd4500 # data-movement start
Data-movement started.

Jak można monitorować przenoszenie danych?

• Stan przenoszenia danych można sprawdzić, używając poniższego polecenia. Na przykład:   

data-movement status

sysadmin@dd4500 # data-movement status
Data-movement to cloud tier:
----------------------------
Data-movement is initializing..

Data-movement recall:
---------------------
No recall operations found. 

• Jeśli przenoszenie danych jest uruchomione, można użyć poniższego polecenia, na przykład:   

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

Jak można zatrzymać przenoszenie danych?

• Można użyć poniższego polecenia. Na przykład:   

data-movement stop 

sysadmin@dd4500 # data-movement stop
Data-movement stop initiated. Run the status command to check its status.

Jeśli istnieje więcej niż jedna jednostka chmury, czy przenoszenie danych może się odbywać równolegle do obu jednostek chmury?

• Nie. Zasadniczo przenoszenie danych może migrować dane tylko do jednej jednostki chmury na raz.

Jak wygląda konfiguracja LTR?

• To jest ogólne omówienie. Szczegóły można znaleźć w podręczniku administracji DDOS.
• Dodaj odpowiedni CLOUDTIER_CAPACITY license.
• Ustaw hasło systemowe, jeśli nie zostało jeszcze ustawione.
• Włącz funkcję chmury.
• Dodaj pamięć masową metadanych dla warstwy chmury.
• Skonfiguruj profil w chmurze lub profil odpowiedniego dostawcy pamięci masowej w chmurze lub obiektowej pamięci masowej.
• Dodaj jednostkę chmury.
• Skonfiguruj zasady przenoszenia danych dla obiektu MTree lub obiektów MTree, które wymagają przechowywania danych w chmurze.
• Rozpocznij przenoszenie danych ręcznie lub poczekaj na rozpoczęcie automatycznego albo zaplanowanego przenoszenia danych.

Czy można usunąć jednostkę chmury? Jeśli tak, to w jaki sposób?

• Przestroga: To działanie spowoduje zniszczenie wszelkich danych przechowywanych w jednostce chmury i nie będzie można ich odzyskać, dlatego należy postępować ostrożnie.
• Zapoznaj się z sekcją „W jaki sposób użytkownik ustala, w jakiej warstwie znajduje się plik?” w tym dokumencie bazy wiedzy, aby dowiedzieć się, które pliki znajdują się w jednostce chmury, która ma zostać usunięta.
• Te pliki należy albo usunąć, jeśli nie są już potrzebne, albo odwołać do warstwy aktywnej, jeśli trzeba je zachować.
• Jeśli pliki muszą zostać zachowane, przed kontynuowaniem trzeba koniecznie odwołać wszystkie plików.
• W jednostce chmury, która zostanie usunięta, nie powinno być żadnych plików.
• Zresetuj wszystkie zasady przenoszenia danych dla obiektu MTree lub obiektów MTree korzystających z tej jednostki chmury.
• Wyłącz system plików.
• Usuń jednostkę chmury. To spowoduje zaznaczenie, że jednostka chmury jest w stanie DELETE_PENDING, co jest zgodne z założeniami.
• Włącz system plików.
• Po uruchomieniu system plików asynchronicznie rozpoczyna usuwanie wszystkich obiektów w pamięci masowej w chmurze lub obiektowej pamięci masowej, które były używane przez tę jednostkę chmury. Po usunięciu wszystkich obiektów usuwane są również zasobniki używane przez jednostkę chmury. W przypadku istnienia wielu obiektów jednostka chmury może pozostawać w stanie DELETE_PENDING przez dłuższy czas.
• Po pomyślnym usunięciu wszystkich obiektów i zasobników jednostka chmury znika z listy jednostek chmury.

Co się stanie, jeśli nie uda się usunąć jednostki chmury, ponieważ obiektowa pamięć masowa nie jest już dostępna lub wystąpił problem z łącznością?

• W celu uzyskania dalszej pomocy skontaktuj się z Dell Support.

Czy LTR i ER (rozszerzone przechowywanie) można skonfigurować w tym samym systemie?

• Nie. ER i LTR to wzajemnie wykluczające się funkcje.

Jak dane są uwalniane lub usuwane z warstwy chmury?

• Działa to w podobny sposób jak pliki znajdujące się w warstwie aktywnej
• Po osiągnięciu okresu retencji plik jest usuwany z przestrzeni nazw systemu plików.
• Zaplanowane jest uruchomienie procesu czyszczenia warstwy chmury. Domyślnie czyszczenie warstwy chmury zostaje uruchomione po każdych czterech sesjach czyszczenia warstwy aktywnej.
• Aby proces czyszczenia warstwy chmury mógł zostać uruchomiony, czyszczona jednostka chmury musi mieć co najmniej 1% zbędnych lub możliwych do wyczyszczenia danych. Dzieje się tak, ponieważ wszelki ruch sieciowy w chmurze może być płatny, więc system DDR stara się ograniczyć ruch sieciowy tam, gdzie to możliwe.
• Warstwa chmury działa z domyślną prędkością czyszczenia 50%.
• Można zmienić zarówno harmonogram czyszczenia warstwy chmury, jak i prędkość czyszczenia.
• Czyszczenie warstwy aktywnej i warstwy chmury nie może działać równolegle.
• Uruchomione automatyczne lub zaplanowane czyszczenie warstwy chmury jest wywłaszczane przez czyszczenie warstwy aktywnej.
• W przypadku ręcznego zainicjowania czyszczenia warstwy chmury czyszczenie warstwy aktywnej nie może się rozpocząć do momentu ukończenia czyszczenia warstwy chmury.
• Jeśli warstwa chmury ma dwie jednostki chmury, zaplanowane lub automatyczne czyszczenie warstwy chmury jest realizowane tylko w odniesieniu do jednej z nich. Jednostki chmury są obsługiwane zgodnie z algorytmem karuzelowym z punktu widzenia czyszczenia warstw chmury. Jeśli istnieją dwie jednostki chmury, wymagane jest określenie jednostki chmury do czyszczenia podczas uruchamiania w wierszu polecenia (cloud clean start <nazwa-jednostki>)
• Jeśli czyszczenie warstwy chmury w jednostce chmury nie rozpocznie się, na przykład gdy bieżąca jednostka chmury nie ma wystarczającej ilości danych do oczyszczenia, aby system uznał, że warto zrealizować ten proces, automatycznie zostanie podjęta próba czyszczenia danych z następnej jednostki chmury.
• Aby uzyskać więcej informacji na temat czyszczenia warstwy chmury, zobacz następujący artykuł Data Domain: Wprowadzenie do retencji długoterminowej, czyszczenia warstwy chmury i odśmiecania pamięci w systemach Data Domain Restorer (DDR)

Jak rozpocząć ręczne czyszczenie warstwy chmury?

• Można użyć poniższego polecenia. Na przykład:   

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.

Jak można monitorować czyszczenie warstwy chmury?

• Używając poniższego polecenia, można sprawdzić, czy trwa czyszczenie chmury. Na przykład:   

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.

• Jeśli czyszczenie chmury jest uruchomione, proces można monitorować za pomocą poniższego polecenia:

cloud clean watch

Czy czyszczenie warstwy aktywnej może przebiegać równolegle z czyszczeniem warstwy chmury?

• Nie. Zarówno czyszczenie warstwy aktywnej, jak i czyszczenie warstwy chmury korzystają z tych samych wspólnych wewnętrznych struktur danych, które wymagają wyłącznego dostępu.

Jak można wyświetlić lub zmienić harmonogram czyszczenia warstwy chmury?

• Używając poniższego polecenia, można wyświetlić aktualny harmonogram czyszczenia chmury. Na przykład:   

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.

• Poniższe polecenie służy do zmiany harmonogramu. Na przykład:  

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.

Jak można zmienić lub wyświetlić prędkość czyszczenia warstwy chmury?

• Domyślnie prędkość czyszczenia warstwy chmury jest ustawiona na 50%. Używając poniższego polecenia, można zresetować ją do domyślnej wartości procentowej prędkości czyszczenia.

cloud clean throttle reset

• Używając poniższego polecenia, można wyświetlić bieżącą prędkość czyszczenia chmury. Na przykład:   

cloud clean throttle show

sysadmin@dd4500 # cloud clean throttle show
Cloud tier cleaning throttle is set to 28 percent

• Używając poniższego polecenia, można zmienić prędkość czyszczenia. Na przykład:   

cloud clean throttle set <value> 

sysadmin@dd4500 # cloud clean throttle set 20
Cloud tier cleaning throttle set to 20 percent

Co kontroluje prędkość czyszczenia warstwy chmury?

• Prędkość czyszczenia warstwy chmury działa w podobny sposób do prędkości czyszczenia warstwy aktywnej, ponieważ ogranicza zasoby we/wy i procesora, z których może korzystać proces czyszczenia warstwy chmury.
• Nie ogranicza prędkości transferu sieciowego.

Dlaczego czyszczenie warstwy chmury nie zwalnia/nie usuwa tylu obiektów, ile oczekiwano?

• Czyszczenie zawsze jest uważane za szacunkowe. Zapoznaj się z następującymi artykułami bazy wiedzy, które opisują aspekty związane z tym tematem, ponieważ dotyczą one w równym stopniu danych znajdujących się w warstwie chmury:  

• Ponadto istnieją dalsze szczegółowe informacje dotyczące sposobu implementacji warstwy chmury.
• Wdrożono różne metody ograniczania ruchu sieciowego do dostawcy pamięci masowej w chmurze lub obiektowej pamięci masowej, ponieważ może to się wiązać z kosztami.
• Jak wspomniano powyżej, aby proces czyszczenia mógł zostać uruchomiony, wymagany jest co najmniej 1% danych dostępnych do czyszczenia.
• Podczas przeszukiwania systemu plików w celu wyszukania plików spełniających zasady przenoszenia danych sprawdzane są tylko lokalne kopie metadanych.
• Wszystkie segmenty przechowywane w pamięci masowej w chmurze lub obiektowej pamięci masowej, które przechowują tylko dane użytkownika, są oznaczane do asynchronicznego usunięcia.
• Wszystkie segmenty zawierające co najmniej jeden żywy segment są pomijane, ponieważ DDOS nie chce łączyć małych ilości danych ze względu na ruch sieciowy.

W jaki sposób użytkownik ustala, w jakiej warstwie znajduje się plik?

• Użyj poniższego polecenia, aby uzyskać przykład danych wyjściowych wygenerowanych przez to polecenie:  

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

Czy plik można odczytać lub uzyskać do niego dostęp bezpośrednio po jego migracji do warstwy chmury?

• To zależy od używanej wersji DDOS wraz z dostawcą rozwiązań chmurowych:   

• Bezpośrednie przywracanie plików jest możliwe bez konieczności wcześniejszego odwoływania pliku. Jest to tzw. funkcja „przywracania bezpośredniego” i jest ograniczona do ECS jako dostawcy chmury lub obiektów.
• Więcej informacji na temat „przywracania bezpośredniego” z Avamar można znaleźć w opracowaniu „Przywracanie w systemie Avamar na poziomie szczegółowym lub na poziomie pliku z Data Domain Cloud Tier”.
• Funkcja Avamar GLR/FLR (przywracanie bezpośrednie) wymaga minimalnej kombinacji Avamar 18.1 lub DDOS 6.1 z ECS jako dostawcą rozwiązań chmurowych. 

• Najpierw należy odwołać plik. Oznacza to, że dane zostają przeniesione z powrotem z warstwy chmury do warstwy aktywnej.
• Plik musi zostać odwołany z warstwy chmury do warstwy aktywnej przy użyciu polecenia odwołania przeniesienia danych, aby można było odczytać lub zmodyfikować plik znajdujący się w warstwie chmury.
• Jeśli plik nie zostanie najpierw odwołany, to każda próba odczytania lub zmodyfikowania pliku znajdującego się w warstwie chmury powoduje zwrócenie błędu we/wy każdemu, kto próbuje odczytać plik, to znaczy aplikacji do tworzenia kopii zapasowych.
• Niektóre aplikacje do tworzenia kopii zapasowych obsługujące chmurę mogą inicjować odwoływanie plików, w przeciwnym razie pliki trzeba odwołać ręcznie.
• Począwszy od DDOS 7.7+:
  • Przywracanie bezpośrednie umożliwia niezintegrowanym aplikacjom odczytywanie plików bezpośrednio z warstwy chmury bez przechodzenia przez warstwę aktywną.
  • Najważniejsze kwestie, które należy wziąć pod uwagę przy wyborze funkcji przywracania bezpośredniego:
  • Przywracanie bezpośrednie nie wymaga zintegrowanej aplikacji i jest niewidoczne dla aplikacji niezintegrowanych.
  • Odczyt z warstwy chmury nie wymaga uprzedniego kopiowania do warstwy aktywnej.
  • Dostępne są histogramy i statystyki do śledzenia bezpośrednich odczytów z warstwy chmury.
  • Przywracanie bezpośrednie jest obsługiwane tylko w przypadku dostawców rozwiązań chmurowych AWS i ECS.
  • Aplikacje doświadczają opóźnień w warstwie chmury.
  • Odczyt bezpośrednio z warstwy chmury nie jest zoptymalizowany pod kątem przepustowości.

Ile plików można odwoływać równolegle?

• System DDOS 6.0 obsługuje kolejkowanie i równoległe odwoływanie czterech plików.
• System DDOS 6.1 obsługuje kolejkowanie 1000 plików, a kolejka odwołań może zawierać 4 pliki do odwoływania równoległego.

Zgodnie z podręcznikiem administratora Data Domain 7.9:

• Systemy z pamięcią 256 GB lub większą mogą odwoływać do 16 plików jednocześnie.
• Systemy z pamięcią poniżej 256 GB pamięci mogą odwoływać do ośmiu plików jednocześnie.
• Wystąpienia DDVE mogą odwoływać do czterech plików jednocześnie.

Jak można odwołać plik?

• Plik można odwołać za pomocą poniższego polecenia. Na przykład:   

data-movement recall path <path-name> 

sysadmin@dd4500 # data-movement recall path /data/col1/mtree1/file1

Jak można odwołać wszystkie pliki w MTree?

• W zależności od wersji DDOS wszystkie pliki w chmurze można odwołać, uruchamiając jedno polecenie, takie jak poniżej:   

sysadmin@dd4500 # data-movement recall mtree /data/col1/mtree1

• Szczegółowe informacje można znaleźć w „Podręczniku referencyjnym poleceń Dell DDOS” dla danej wersji DDOS.

Jak można monitorować operację odwoływania?

• Operację odwoływania można monitorować za pomocą poniższego polecenia lub jeśli wymagany jest określony plik. Na przykład:   

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 

Czy zmiana nazwy pliku powoduje jego odwołanie z warstwy chmury do warstwy aktywnej?

• Nie. Jeśli nazwa pliku zostanie zmieniona, pozostanie on na bieżącym poziomie.

Jacy dostawcy rozwiązań chmurowych są obsługiwani?

•  W zależności od używanej wersji system DDOS obsługuje następujących dostawców rozwiązań chmurowych:   
• Amazon Web Services (AWS).
• Chmura Microsoft Azure
• Dell Elastic Cloud Storage (ECS)
• Virtustream
• Więcej informacji można znaleźć w podręczniku administratora DDOS.

Czy szyfrowanie jest obsługiwane w warstwie chmury i czy wymaga licencji?

• Tak, szyfrowanie jest obsługiwane w warstwie chmury. Nie wymaga to dodatkowej licencji, w przeciwieństwie do szyfrowania w warstwie aktywnej.
• Można to skonfigurować, gdy funkcja chmury zostanie później włączona lub zmodyfikowana. 
• W chwili pisania tego tekstu szyfrowanie warstwy chmury jest obsługiwane wyłącznie przez wbudowany menedżer kluczy i w całym systemie może być używany tylko jeden algorytm szyfrowania dla funkcji LTR.

Jakie zasobniki są tworzone w magazynach obiektów dostawców chmury?

• DDOS tworzy trzy zasobniki
• Zasobniki są zakończone ciągiem:

'-d0'

'-c0' 

'-m0'

• Zasobnik zakończony ciągiem „-d0” jest używany do segmentów danych.
• Zasobnik kończący się ciągiem „-c0” jest używany do danych konfiguracji.
• Zasobnik kończący się ciągiem „-m0” jest używany do metadanych.
• W systemach poprzedzających DDOS 6.1 przy tworzeniu trzech zasobników używany jest tylko zasobnik kończący się ciągiem „-d0”. Jednak wszystkie trzy zasobniki są potrzebne, więc nie można ich usuwać.

Czy możliwe jest użycie istniejących nazw zasobników, które być może zostały wcześniej utworzone?

• Nie, to nie jest możliwe.

Czy oprócz wymagań sprzętowych istnieją inne obowiązkowe wymagania, które są wymagane przed skonfigurowaniem LTR?

• Tak
• W przypadku korzystania z ECS obowiązkowym wymogiem jest moduł równoważenia obciążenia. Bez modułu równoważenia obciążenia Data Domain komunikuje się z ECS w jednym węźle i rozłącza się po wysłaniu wielu żądań.
• Sieć 1 Gb między DDR a dostawcą rozwiązań chmurowych

Czy wymagane są certyfikaty, a jeśli tak, to jakich certyfikatów należy użyć?

• To zależy od używanego obiektu lub dostawcy chmury, a także konfiguracji.
• AWS, Virtustream lub Azure wymagają certyfikatu. Więcej informacji można znaleźć w podręczniku administratora DDOS.
• Jeśli ECS jest skonfigurowany przy użyciu punktu końcowego http, certyfikat nie jest wymagany.
• Jeśli ECS jest skonfigurowany przy użyciu punktu końcowego https, wymagany jest certyfikat. Ponieważ moduł równoważenia obciążenia jest obowiązkowym wymogiem, niezbędny certyfikat pochodzi z modułu bilansowania obciążenia, a nie z systemu ECS. Aby uzyskać więcej informacji, skontaktuj się z dostawcą modułu równoważenia obciążenia.
• Importowany certyfikat musi być w formacie PEM. Niektórzy dostawcy nie udostępniają certyfikatu w formacie PEM, dlatego przed importem należy go przekonwertować.

Jakie topologie replikacji są obsługiwane?

• Replikacja kolekcji nie jest obsługiwana.
• Replikacja katalogów jest obsługiwana, jednak może być używana tylko przez obiekt MTree „/data/coll1/backup”, ale to drzewo MTree nie obsługuje przenoszenia danych.
• Replikacja MTree jest w pełni obsługiwana.
• Replikacja MFR lub VSR jest w pełni obsługiwana.

Co należy wziąć pod uwagę podczas konfigurowania/inicjowania/ponownego inicjowania replikacji w systemie, który ma już skonfigurowaną funkcję LTR?

• System źródłowy wykonuje migawkę drzewa MTree (ta migawka zawiera szczegółowe informacje o plikach w warstwie aktywnej i warstwie chmury).
• System źródłowy replikuje migawkę do warstwy aktywnej systemu docelowego.
• Dopiero po całkowitym zreplikowaniu migawki jest ona widoczna w systemie docelowym (i w tym momencie pliki stają się dostępne w przestrzeni nazw systemu plików systemów docelowych).
• Dopiero po uwidocznieniu plików można uruchomić przenoszenie danych w miejscu docelowym (zakładając, że jest skonfigurowane dla LTR).
• Wskutek tego jeśli aktywna warstwa miejsc docelowych nie będzie wystarczająco duża, aby pomieścić pełną migawkę ze źródła, migawka nigdy nie zostanie uwidoczniona i replikacja nie będzie mogła zakończyć inicjowania.

Co należy wziąć pod uwagę podczas konfigurowania replikacji MFR/VSR w systemie, który ma już skonfigurowaną funkcję LTR?

• Jeśli dane, które zostały już przeniesione do warstwy chmury w źródłowym DDR, muszą zostać zreplikowane, są one automatycznie odwoływane z warstwy chmury do warstwy aktywnej, zanim będą mogły zostać wysłane przez sieć.
• Odwoływanie plików z warstwy chmury do warstwy aktywnej może się wiązać z kosztami lub opóźnieniami.

Dlaczego dane wyjściowe polecenia Data Domain „file system show space” nie odzwierciedlają rzeczywistego rozmiaru pamięci masowej w chmurze lub obiektowej pamięci masowej?

• Ze względu na określony sposób działania pamięci masowej w chmurze lub obiektowej pamięci masowej system Data Domain nie ma możliwości wysyłania zapytań o fizyczny rozmiar urządzenia w chmurze, ponieważ może on być postrzegany jako pozornie nieskończony.
• Jednak DDOS musi mieć opracowany sposób wyświetlania bieżących statystyk użytkowania/deduplikacji z perspektywy DDOS.
• W związku z tym stosuje się jedno z dwóch podejść:

1. Rozmiar warstwy chmury jest określany przez CLOUDTIER_CAPACITY license
2. Rozmiar warstwy chmury jest wyświetlany jako wielokrotność rozmiarów jednostek warstwy aktywnej dla tego typu modelu w zależności od liczby skonfigurowanych jednostek chmury. Więcej informacji na temat rozmiarów warstw aktywnych można znaleźć w podręczniku instalacji sprzętu dla danego modelu.

Jak uruchomić system plików, jeśli jednostka chmury jest niedostępna?

• Upewnij się, że system plików jest wyłączony.
• Wyłącz jednostkę chmury, która jest niedostępna, korzystając z poniższego polecenia:

cloud unit disable <cloud unit name>

• Włącz system plików.

Jeśli jednostka chmury jest wyłączona, jak można ją włączyć?

• Upewnij się, że system plików jest wyłączony.
• Włącz jednostkę chmury za pomocą poniższego polecenia:

cloud unit enable <cloud unit name>

• Włącz system plików.

Dlaczego w systemie plików nadal istnieją pliki znajdujące się w jednostce chmury, która została usunięta?

•  Pliki, które nie zostaną usunięte z drzewa MTree przed usunięciem jednostki chmury, nadal istnieją w przestrzeni nazw systemów plików.
• W związku z tym raport lokalizacji plików pokazuje, że pliki są częścią usuniętej jednostki chmury. Na przykład:  

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

• Pliki można nadal wyświetlić w przestrzeni nazw systemu plików poprzez uzyskanie dostępu do udziału CIFS/NFS dla danego drzewa MTree.
• Plików nie można jednak odczytać, ponieważ jednostka chmury, w której się znajdowały, została usunięta.
• Dlatego jedyną opcją jest usunięcie tych plików, ponieważ ich dane, do których się odnosiły, już nie istnieją.

Czy istnieje możliwość zmiany punktu końcowego lub portów protokołu dla dostawcy rozwiązań chmurowych ECS lub S3 Flexible po utworzeniu jednostki chmury?

• Może to być wymagane na przykład w przypadku zmiany z punktu końcowego http na https lub odwrotnie albo migracji do nowego modułu równoważenia obciążenia.
• W chwili pisania tego tekstu administrator Data Domain nie może wykonać tej zmiany. Rozważa się wprowadzenie tej funkcji w przyszłej wersji DDOS.
• Można to jednak zrealizować, korzystając z pomocy technicznej lub inżynierów.
• Aby można było dokonać tej zmiany, należy wyłączyć system plików.
• Jeśli istnieje taki wymóg, cała konfiguracja poza systemem Data Domain jest wykonywana w pierwszej kolejności, ponieważ gdy po zmianie tego ustawienia zostaje włączony system plików, oczekuje on możliwości komunikowania się przy użyciu zaktualizowanego protokołu lub portu i odczytywania zasobników lub obiektów w taki sam sposób, jak wcześniej.