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.

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

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. Stav DB reflektuje výsledek operace v primárním úložišti, stav na sekundárním úložišti může být jiný, pokud se operace nezdařila.

Například v případě že jsou zapojena dvě logická úložiště (A-primární,B) a požadavek DELETE na úložišti A selže, zatímco na úložišti B projde:

úložiště A bude pravděpodobně obsahovat metadata v původním stavu, např. ARCHIVED
úložiště B bude obsahovat metadata v žádoucím stavu, tedy DELETED
DB bude obsahovat stav DELETION_FAILURE

Stav v DB	Popis	Možné stavy na primárním 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 primární úložiště.	<metadata nepřítomna> PROCESSING ARCHIVED ROLLED_BACK
ARCHIVED	Objekt byl úspěšně uložen na primární úložiště. Započala distribuce na sekundární ú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 primárním úložišti se objekt přepne do stavu ARCHIVED. V případě chyby na primárním úložišťi je na všechna úložiště zaslán požadavek na ROLLBACK.

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 primární logické úložiště obsahuje 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.

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

Úloha kontroly konzistence je spouštěna v periodě definované v application.yml. Běh úlohy je vykonán pouze pokud jsou fronty všech úložišť prázdné, v opačném případě je běh přeskočen. Běh kontroluje stav na všech 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ém běhu 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. Iniciace zapojení je možná pouze pokud jsou fronty všech úložišť prázdné. Po úspěšné odpovědi na volání API startuje na pozadí proces synchronizace dat z primárního na nové sekundární úložiště.

Proces synchronizace nového úložiště

jsou ověřeny vstupní podmínky (systém není v read-only režimu, nové úložiště je dostupné, …)

nové úložiště je zapsáno do DB

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ů

v novém úložišti jsou vytvořeny dataspaces a je vytvořena JMS fronta + consumer

do fronty jsou vloženy zprávy COPY pro všechny objekty v Archival Storage

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

Nastane-li při synchronizaci chyba, úložiště je odpojeno a je zaslán email administátorovi, který může synchronizaci opět spustit zapojením úložiště příslušným endpointem.