12.2. Popis funkcionalit

Archival Storage pracuje na nižších úrovních s veškerými nahranými soubory jako s objekty. Do složky daného logického úložiště jsou uloženy:

• objekt datové části AIP (ZIP)

• 1-n AIP XML objektů

• pro každý objekt je uložen metadatový soubor s názvem {nazevobjektu}.meta

Metadatový soubor obsahuje údaje nezbytné k rekonstrukci databáze v případě její ztráty:

• časovou značku vytvoření

• typ kontrolního součtu

• původní hodnotu kontrolního součtu

• stav

Časová značka vytvoření je shodná pro datový objekt a jeho první AIP XML. V případě že je v systému nad objektem proveden ROLLBACK a následovný opětovný pokus o uložení, objekt stále nese původní časovou značku.

12.2.1. Volitelné funkcionality

Tyto funkcionality jsou v Archival Storage defaultně vypnuty. Lze je povolit v application.yml v sekci arcstorage.optionalFeatures

Forget

Funkcionalita umožňuje úplné smazání balíčku, t.j. i AIP XML a to jak z úložiště tak z DB. Více informací o této funkcionalitě níže v této dokumentaci.

V současnosti je tato funkcionalita na úrovni úložiště implementována pouze pro lokální (nebo NFS) FS/ZFS. Tato funkcionalita by měla být v konfiguraci vypnutá pokud systém využívá i FS/ZFS skrze SSH nebo Ceph.

Inkrementální zálohování

Funkcionalita umožňuje inkrementální zálohování, přesněji využití parametru since při volání endpointu pro zálohování.

V současnosti je tato funkcionalita na úrovni úložiště implementována pouze pro lokální (nebo NFS) FS/ZFS. Tato funkcionalita by měla být v konfiguraci vypnutá pokud systém využívá i FS/ZFS skrze SSH nebo Ceph.

12.2.2. Stavy objektů

Chybovost úložišť a zapojení více logických úložišť mohou zapříčinit nekonzistentní stav objektu v databázi a na jednotlivých úložištích. Například v případě že jsou zapojena dvě logická úložiště (A,B) a požadavek DELETE se na úložišti A povede, přičemž na úložišti B selže, metadata úložiště A budou obsahovat stav DELETED, metadata úložiště B možná stále stav ARCHIVED. Stav v DB v tomto případě bude DELETION_FAILURE.

Stav v DB	Popis	Možné stavy na logickém úložišti
PRE_PROCESSING	Úvodní fáze. Během této fáze je kontrolován kontrolní součet po přenosu apod.	<metadata nepřítomna>
PROCESSING	Objekt je ukládán na všechna logická úložiště.	<metadata nepřítomna> PROCESSING ARCHIVED ROLLED_BACK
ARCHIVED	Objekt byl úspěšně uložen na všechna logická úložiště.	ARCHIVED
ROLLED_BACK	Objekt byl systémově smazán.	ROLLED_BACK
DELETED	Objekt je smazán, jeho metadata zůstávají na úložišti. Tento stav může nabývat pouze datový objekt. V AIS se tento stav využívá při tvorbě nové datové verze - je smazán původní datový objekt.	DELETED
REMOVED	V AIS nepoužito.	V AIS nepoužito.
ARCHIVAL_FAILURE	Uložení objektu se nezdařilo a následovný (automaticky volaný) pokus o ROLLBACK se také nezdařil.	<metadata nepřítomna> PROCESSING ARCHIVED ROLLED_BACK
DELETION_FAILURE	Smazání objektu se nezdařilo.	ARCHIVED DELETED
ROLLBACK_FAILURE	Systémové mazání objektu se nezdařilo.	<všechny možnosti>
FORGOT	Objekt je smazán z úložiště i z DB. V DB zůstává pouze audit operace a na úložišti pouze jeho metadata.	FORGOT, ARCHIVED, DELETED, REMOVED, ROLLED_BACK

Veškeré operace probíhající nad AIP jako celkem jsou prováděny současně nad datovým objektem i první verzí AIP XML. Výjimkou je mazání (DELETED) a jeho případné chybové řízení.

Stavy lze rozdělit do čtyř skupin:

Nedokončené (PRE_PROCESSING, PROCESSING) Při úspěšném uložení na všech úložištích se objekt přepne do stavu ARCHIVED. V případě chyby na jednom z úložišť je na všech úložištích proveden pokus o ROLLBACK. V případě neúspěšného ROLLBACKu na jednom z úložišť je stav v DB nastaven na ARCHIVAL_FAILURE.

Objekt ve stavu PROCESSING může čekat na přidělení vlákna.

Po pádu aplikace již nelze objekt z nedokončeného stavu přepnout do jiného dokončeného stavu než ROLLED_BACK. V případě nastavení arcstorage.cleanUpAtApplicationStart=true je při novém startu aplikace proveden pokus o ROLLBACK takovýchto objektů. V případě neúspěchu zůstává v DB původní stav. Obdobně lze pokus provést voláním POST /api/administration/cleanup?all=true

Dokončené (ARCHIVED, DELETED, ROLLED_BACK, REMOVED) Pouze při těchto stavech je očekáváno že všechna logická úložiště obsahují metadata konzistentní s metadaty v DB. Do těchto stavů lze objekt standardně přepnout skrze API.

Chybové (ARCHIVAL_FAILURE, DELETION_FAILURE, ROLLBACK_FAILURE) Stejně jako v případě nedokončených stavů lze pomoci funkcionality cleanup přepnout objekt do dokončeného stavu. V případě stavu DELETION_FAILURE je příslušným dokončeným stavem stav DELETED, v ostatních případech stav ROLLED_BACK.

Forget (FORGET) Po zavolání forget API je objekt (pokud se jedná o datový objekt pak i všechna jeho AIP XML) smazán v úložišti/úložištích. V úložišti zůstává uchovaný pouze metadatový soubor v němž je garantována pouze přítomnost stavu FORGET (může chybět checksum, časová značka, …). Následně je objekt (objekty) smazán i z DB a průběh operace je zapsán do auditní tabulky. Volání je synchronní, pokud operace selže volající by měl volání opakovat.

12.2.3. Periodické kontroly

Archival Storage periodicky kontroluje dostupnost logických úložišť, stav logických úložišť a konzistenci uložených objektů.

Dostupnost logických úložišť

Kontrola dostupnosti všech připojených logických úložišť probíhá v periodě definované v entitě arcstorage_system_state. Hodnotu lze změnit bez nutnosti restartovat aplikaci skrze API. V případě nedostupnosti některého z úložišť je zaslán email všem administrátorům.

Stav logických úložišť

Report stavu všech připojených logických úložišť probíhá v periodě definované v souboru application.yml. Všem administrátorům je v každé periodě zaslán email.

Konzistence uložených objektů

Kontrola konzistence probíhá v periodě definované v application.yml na všech připojených logických úložištích. Kontrolovány jsou pouze objekty datové části AIP (ZIP). Kromě periody je zde konfigurován počet AIPů zkontrolovaných v rámci jedné periody (s možností hodnotu vynechat a kontrolovat tak v rámci každé periody všechny AIPy).

AIPy jsou kontrolovány od nejstaršího po nejnovější. V každé periodě je zkontrolováno n AIPů a po kontrole je v DB zaznačena časová značka posledního zkontrolovaného. Následující perioda pokračuje s balíky od poznačené časové značky. Po zkontrolování všech AIP začíná cyklus odznova. V případě neočekávané chyby během kontroly (např. nedostupného úložiště) je chyba zaznamenána do logu, a příští perioda provádí kontrolu nad stejnou množinou AIP.

Informace o úspěšné kontrole validních AIP není reportována.

V případě nevalidních AIP které jsou v DB vedené jako dokončené je automaticky proveden pokus o opravu invalidní kopie na problémovém úložišti validní kopií na jiném úložišti. O výsledcích opravných pokusů je na konci procesu oprav zaslán email všem administrátorům.

AIPy jež jsou v DB v chybovém stavu nebo jsou v nedokončeném stavu déle než den nejsou automaticky opravovány. O těchto je zaslán samostatný notifikační email všem administrátorům. Email doporučuje úložiště od balíků “očistit” skrze API (cleanup).

12.2.4. Připojení nového úložiště

ADMIN může skrze API připojit nové logické úložiště za běhu systému. Po úspěšné odpovědi na volání API startuje na pozadí proces synchronizace dat z existujících úložišť na nové úložiště.

Fungování systému v průběhu synchronizace

• Veškeré nově příchozí objekty zapisovány na všechna úložiště (včetně nového).

• Operace čtení jsou odbaveny z původních úložišť.

• Nově příchozí operace REMOVE/RENEW/DELETE/ROLLBACK/ARCHIVAL_RETRY/FORGET jsou z počátku propagovány pouze na původní úložiště, na nové úložiště jsou propagovány v pozdější fázi synchronizace.

• Pokud při synchronizaci došlo k chybě, administátor může skrze API vyžádat informace o stavu synchronizace, chybu opravit a poté zavolat endpoint pro pokračování v synchronizaci.

Proces synchronizace (nové úložiště = S2)

1. Jsou ověřeny vstupní podmínky (systém není v read-only režimu, S2 je dostupné, …). S2 má nastaven příznak synchronizing =true a je zapsáno do DB.

2. Fáze INIT

• systém je přepnut do read-only režimu

• čeká se na dokončení všech právě probíhajících transakcí a procesů balíků

• na S2 jsou vytvořeny dataspace s

• je poznačena časová značka T1

• systém je přepnut do read-write režimu

3. Fáze COPYING_ARCHIVED_OBJECTS

• Všechny objekty s časovou značkou vytvoření < T1 jsou kopírovány na S2 v jejich aktuálních stavech

• Po této fázi obsahuje S2 záznam o všech objektech v systému (objekty archivované před T1 byly zkopírovány z původních úložišť, objekty archivované po T1 byly na úložiště uloženy přímo).

Poznámka: Může se stát že O1 (AIP) a O2 (AIP XMLv1) byly uloženy v čase < T1 ale ještě nebyly zkopírovýny na S2, přesto S2 přijme nově příchozá objekt O3 (AIP XMLv2). Kolize v tomto případě nenastává, protože logické úložiště nijak neoperuje s vztaženými objekty (vztahy a verzování jsou řešeny ve vyšších vrstvách systému).*

4. Fáze PROPAGATING_OPERATIONS

• Operace REMOVE/RENEW/DELETE/ARCHIVAL_RETRY/FORGET zaznamenané po čase T1 jsou zpropagovány na nové úložiště

• Systém je přepnut do read-only režimu

5. Fáze SYNC_CHECK

• Systém zkontroluje že nové úložiště obsahuje validní metadata všech objektů uložených v DB.

• Kontrolní součty dat na novém úložišti byly kontrolovány již při kopírování v předchozích fázích a proto nejsou kontrolovány znovu.

• Systém je přepnut do read-write režimu a logickému úložišti je nastaven příznak synchronizing =false.

6. Fáze DONE