%=========================================================================
% (c) Michal Bidlo, Bohuslav Křena, 2008


\chapter{Úvod}
Během začátku 21. století došlo k~ohromnému růstu v~oblastech internetu, sociálních sítí, multimédií, chytrých telefonů či dalších digitálních zařízení, mobilních plateb a~on-line transakcí. V~podstatě ve všech oblastech jako je např. věda, politika, medicína, doprava, energetika, se nevyhneme použití digitálních zařízení. S~tím velmi úzce souvisí nárůst objemu digitálních dat, která je potřeba ukládat, analyzovat, zpracovávat, a~také vyšetřovat.

Digitální zařízení se mohou stát terčem útoků, může se jednat o~krádež citlivých dat, podvržení dat, sledování a~další. Digitální zařízení mohou být také nástrojem zločinu.

Rozdílnost mezi formáty digitálních dat, jejich strukturované a~nestrukturované vlastnosti, a~také prudký nárůst vyžadují mnoho rozličných přístupů a~technologií pro jejich zpracování.

Cílem této práce je navrhnout a~vytvořit distribuované úložiště pro digitální forenzní data. V~rámci teoretické části práce, se kapitola \ref{chapter1} zaměřuje na forenzní analýzu digitálních dat. Vysvětluje jak probíhá a~co je jejím cílem. Zabývá se také formáty digitálních forenzních dat a~existujícími systémy, které slouží k~uchování těchto dat a~důkazního materiálu. Následně je představen systém AFF4.

Kapitola \ref{chapter2} pojednává o~úložištích pro rozsáhlá strukturovaná i~nestrukturovaná data. V~jejich kontextu vysvětluje také termín Big data. Následují odstavce zaměřeny na distribuované databáze včetně jejich výhod a~nevýhod. Kapitola je završena uvedením principů NoSQL databází, rozdělení podle typů, a~srovnání s~relačními databázemi. Na NoSQL databázích bude založeno úložiště distribuovaného repositáře.

Cílem praktické části práce je navrhnout a~implementovat distribuovaný repositář. V~kapitole návrhu \ref{distrRepDesignChapter} je vysvětlena architektura systému, aplikační rozhraní, vlastnosti úložišť, princip ovládání repositáře a~také rozšiřitelnost pro nové druhy digitálních forenzních dat. Systém využívá Big data technologie. Pro komunikaci s~klientem jsou zprávy přenášeny pomocí platformy Kafka. Jako úložiště slouží, v~závislosti na tom, o~jaký typ forenzních digitálních dat se jedná, NoSQL databáze a~distribuovaný souborový systém HDFS.

Kapitola \ref{chapter_impl} se zabývá implementací distribuovaného úložiště,  technickými detaily, způsobem asynchronní komunikace s~databázemi, ukládáním a~dotazováním nad daty (sekvenčním i~náhodným). Systém pracuje nad frameworkem Spring Boot, který usnadňuje konfiguraci a~použití Big data komponent. Jako běhové prostředí byl zvolen projekt \texttt{Docker}, který poskytuje jednotné rozhraní pro izolaci aplikací do kontejnerů.

Poslední kapitola \ref{chapter_performance} se věnuje výkonnosti systému, hardwarovým požadavkům a~konfiguraci, a~použití systému pro vybrané druhy digitálních forenzních dat.

V~rámci semestrálního projektu byly zpracovány kapitoly týkající se teoretické části \ref{chapter1}, \ref{chapter2} a~\ref{distrRepDesignChapter}. Byl také implementován jednoduchý prototyp systému, kterým se zabývá sekce \ref{prototypeSection}.

\chapter{Forenzní analýza digitálních dat} \label{chapter1}
Forenzní analýza digitálních dat je věda identifikující, zachovávající, obnovující, analyzující a~předávající fakta ohledně digitálních důkazů nalezených v~počítačích nebo digitálních úložištích mediálních zařízení.
Nezabývá se tedy pouze počítači, ale také ostatními digitálními technologiemi včetně mobilních telefonů a~tabletů, mobilních sítí, internetového bankovnictví, datových médií apod.

Forenzní analýza digitálních dat slouží k~získání digitálního důkazního materiálu, který může být použit v~soudní síni proti obviněnému. Nalezené výstupy nejsou omezeny k~použití pouze u~soudu. Častokrát může nějaká firma řešit interní záležitosti jako například porušení firemní politiky, kdy se zase musí najít (digitální) důkaz, který potvrzuje nebo vyvrací obvinění.

Pod výše uvedenými aktivitami se skrývá \cite{whatIsDigFor}:

\begin{itemize}
\item Identifikace -- Jedná se o~první část celého procesu. Předtím, než je cokoliv zkoumáno a~analyzováno, je důležité identifikovat, kde jsou data uložena. Typicky jsou uložena na diskových jednotkách, serverech, flash paměti, nebo síťových zařízeních.

\item Zachování -- Důležitá je ochrana důkazů, tzn. pro sběr a~analýzu informací je potřeba zachovat původní data, musí se zabránit jejich změně a~ztrátě. Bez integrity je důkazní materiál nepoužitelný. Identifikovaná původní data mohou být zajištěna chronologickým řetězcem dokumentů (anglicky \texttt{chain of custody}), který zaznamenává veškeré aktivity s~digitálním důkazem jako je přenos, úschova, kontrola a~stav.

\item Obnovení -- Součástí procesu je i~obnova dat, která může zahrnovat obnovu smazaných dat procesy operačního systému, úmyslně smazané soubory, soubory chráněné heslem a~také poškozené soubory. I~po obnovení smazaného souboru musí být stále zachována integrita.

\item Analýza -- Jedná se o~hlavní část vyšetřování. Cílem je shromáždit co nejvíce relevantních artefaktů. Prohledávána je paměť, registry, výpisy z~logů aplikací, historie internetového prohlížeče apod. Podstatná je i~dokumentace všech kroků, které byly provedeny.

\item Předání -- Po analýze jsou artefakty důkladně zdokumentovány a~odevzdány například ve formě protokolu. Po shromáždění všech nalezených informací může ale nemusí dojít k~definitivnímu rozhodnutí. Co se s~informacemi stane už není v~rukou vyšetřovatele. Tady proces forenzní analýzy končí.
\end{itemize}

\noindent Vyšetřování digitálních forenzních dat obvykle zahrnuje vytvoření forenzní duplikace zkoumaného média. Provádí se proto, aby se neznehodnotil původní zdroj. Například dojde k~vytvoření obrazu disku, který je kopií celého disku nebo jeho části bit po bitu. Neduplikuje se celý systém, pokud je prostor příliš velký. Obraz je statický snímek, který může být analyzován za účelem odhalení nebo stanovení událostí ohledně incidentů, a~může tak být použitý jako důkaz v~soudní síni. Analýza je prováděna na kopii pro zachování integrity originálu.

Vyšetřovatel zanalyzuje obraz pomocí snímacích technik, aby získal relevantní data z~disku. Forenzní obraz obsahuje soubory z~disku, nealokovaný prostor a~tzv. \texttt{slack space}. Slack space je pozůstatek diskového prostoru, který byl alokován pro nějaký počítačový soubor a~ten všechen prostor nepotřebuje. Právě v~těchto prostorech mohou být nalezeny relevantní artefakty a~informace jako např. smazané soubory, či jejich fragmenty \cite{forensicImages}.

\begin{figure}[!h]
  \centering
  \includegraphics[width=10.5cm]{template-fig/SlackSpace.pdf}
  \caption{Příklad znázorňuje slack space pro parametry -- sektory velikosti 512 bytů jsou shluknuty v~operačním systému do skupin po čtyřech, tzn. velikost svazku je 2048 bytů; velikost souboru je 1280 bytů (vyznačen modrou barvou). Pro tento soubor byl alokován celý svazek 2048 bytů. Nevyužité místo (označeno bílou barvou) je slack space, v~tomto případě se jedná o~768 bytů \cite{slacSpace}.}
  \label{FIG_SlackSpace}
\end{figure}

\section{Formáty digitálních forenzních dat}
Typů digitálních forenzních dat existuje spousta. Každý typ takových dat může být reprezentován jiným formátem. Tato sekce čerpá informace převážně z~\cite{forensicswikiForensicFF}.

Mnoho forenzních počítačových programů používá své vlastní formáty pro uložení informace. Můžeme je rozdělit na nezávislé (anglicky \texttt{Independent File Formats}) a~programově specifické formáty (anglicky \texttt{Program-Specific File Formats}):

\begin{itemize}
\item Nezávislé -- Tyto formáty byly vyvinuty nezávisle na konkrétním forenzním programu. Patří mezi ně \texttt{AFF}, \texttt{AFF4}, \texttt{gfzip}, \texttt{Raw Image Format}.

\item Programově specifické -- Byly vyvinuty pro použití specifickými forenzními programy. Většinou každý takový formát je unikátní, a~proto je pro přečtení potřeba unikátního nástroje.
Zástupci jsou například \texttt{Encase image file format}, \texttt{ProDiscover image file format}, \texttt{IXimager file formats}.
\end{itemize}

\subsubsection{Identifikace formátu}
%File Format Identification
Identifikace formátu souboru je proces určení formátu nějaké sekvence bytů. Operační systém toto typicky dělá rozpoznáním přípony souboru nebo podle zabudované \texttt{MIME} informace. Forenzní aplikace musí identifikovat typy souborů podle obsahu. Mezi existující systémy patří například tyto projekty -- \texttt{libmagic}, \texttt{PRONOM}, \texttt{Apache Tika} \footnote{http://tika.apache.org/} \cite{forensicswikiFFIdentification}.

\section{Existující systémy}
Vyznamným zástupcem pro uložení digitálních forenzních dat je systém AFF4, který bude popsán detailněji.

\subsection{AFF4}
Jedná se o~open source formát pro ukládání digitálních důkazů a~dat. Jeho výhodami jsou správa metadat a~možnost komprese. Tato sekce čerpá převážně z~\cite{aff4}. Je založen na objektově orientované architektuře. Veškerá množina známých objektů je označována jako \texttt{AFF4 universe}. Takový prostor je definovaný jako nekonečný, protože AFF4 je navržen pro škálování obrovského množství důkazního materiálu. Všechny objekty jsou adresovatelné jejich jménem, které je v~rámci AFF4 universe unikátní.

\vspace{0.5cm}

\noindent Příkladem jména nějakého AFF4 objektu může být:

\texttt{urn:aff4:f3eba626-505a-4730-8216-1987853bc4d2}

\noindent Jedná se o~standardní URN notaci, URN je unikátní.

\vspace{0.5cm}

\noindent AFF4 universe používá RDF notaci pro specifikaci atributů objektů. V~nejjednodušší podobě je RDF množina tvrzení o~objektu ve formátu:

\texttt{Subject   Attribute   Value}

\vspace{0.5cm}

\noindent Příklad:

\noindent \texttt{******** Object urn:aff4:f3eba626-505a-4730-8216-1987853bc4d2 ***********}\\
\texttt{aff4:stored = urn:aff4:4bdbf8bc-d8a5-40cb-9af0-fd7e4d0e2c9e}\\
\texttt{aff4:type = image}\\
\texttt{aff4:interface = stream}\\
\texttt{aff4:timestamp = 0x49E9DEC3}\\
\texttt{aff4:chunk\_size = 32k}\\
\texttt{aff4:compression = 8}\\
\texttt{aff4:chunks\_in\_segment = 2048}\\
\texttt{aff4:size = 10485760}\\

\noindent Příklad ukazuje, že objekt má tyto atributy a~hodnoty. Nazýváme je relace nebo fakta. Celý AFF4 universe je sestavený z~takových faktů.

\noindent AFF4 objekty existují, protože dělají něco užitečného, což závisí na rozhraní, které představují. Aktuálně existuje několik rozhraní, nejvýznamnější jsou \texttt{Volume} a~\texttt{Stream}. Rozhraní objektu je fakt o~objektu, který se nachází v~atributu \texttt{aff4:interface}.

\subsubsection{Rozhraní Volume}
Rozhraní Volume definujeme jako mechanismus ukládání, který dokáže uložit segment (bit binárních dat) pod nějaké jméno, a~získat jej podle tohoto jména. Aktuálně existují dvě implementace -- \texttt{Directory} a~\texttt{ZipFile}.

\begin{itemize}
\item \texttt{Directory Volume} -- Tato implementace ukládá segmenty jako soubory uvnitř běžného adresáře v~souborovém systému. Hodí se zejména v~případech, pokud potřebujeme uložit obraz na souborový systém FAT, přičemž velikost segmentu je malá a~nenarazíme tak na omezení velikosti souboru. Je také možné založit adresář na nějaké HTTP adrese, což umožní používat obraz přímo z~webu.

\item \texttt{ZipFile Volume} -- Jak napovídá název, tato implementace ukládá segmenty uvnitř zip archivu. Malé soubory lze bez problémů otevřít obyčejným průzkumníkem (v~OS Windows např. \texttt{Windows Explorer}) a~data extrahovat. Zase je možné zapsat zip archiv přímo na HTTP server a~používat obraz přímo ze serveru.
\end{itemize}

\noindent Je možné převádět mezi oběma formáty z~jednoho na druhý, extrahovat zip archiv do adresáře a~nebo z~adresáře vytvořit zip archiv.

\subsubsection{Rozhraní Stream}
Streamy jsou základním rozhraním pro ukládání dat obrazu. Stream obsahuje metody typu \texttt{read}, \texttt{seek}, \texttt{tell} a~\texttt{close}. Podporuje ještě \texttt{write}, ale ne k~modifikaci obrazu, nýbrž k~jeho vytvoření (kvůli výše uvedené integritě zdroje). Pokud nějaký AFF4 objekt podporuje rozhraní stream, lze provést náhodné čtení jeho dat. Existuje několik specifických implementací rozhraní stream, některými z~nich jsou:

\begin{itemize}
\item \texttt{FileBackedObjects} -- Stream, který ukládá data v~souboru v~souborovém systému, jehož pozice je určena URN souboru.

\item \texttt{HTTPObject} -- Pozice souboru je udána pomocí URL. Objekt lze ukládat a~číst z~HTTP serveru. Implementace umožňuje přečíst určité rozmezí bytů. Režie síťového provozu mezi klientem a~serverem je minimální. Je možné vyšetřit vzdálený obraz přes HTTP bez potřeby celé kopie obrazu. Z~důvodu bezpečnosti by měl být server pro zápis nějak omezen, například hesly, SSL certifikáty apod. Podpora čtení může být poskytnuta bez omezení, pokud je zdroj dat zašifrován. Zabezpečení serveru je ale mimo rozsah systému AFF4.

\item \texttt{Segments} -- Segmenty jsou komponenty uloženy přímo ve \texttt{Volume}. Volume je zjednodušeně řečeno objekt uchovávající segmenty. Segmenty by měly být použity pro malé streamy, protože prohledávat v~komprimovaných segmentech může být drahá operace. Segmenty jsou užitečné, pokud potřebujeme vytvořit logický obraz nějaké podmnožiny souborového systému (pouze některé soubory) a~ne forenzní obraz celkového systému.

\item \texttt{Image streams} -- Tyto streamy jsou opakem segmentů. Pro velké obrazy nemůžeme použít segmenty, protože by nebyly zkomprimovány efektivně. Image stream ukládá obraz v~tzv. \texttt{chunks}.
\end{itemize}

\chapter{Úložiště pro rozsáhlá strukturovaná i~nestrukturovaná data} \label{chapter2}
V~této kapitole bude představen a~vysvětlen termín Big data, následován systémy a~mechanismy pro uložení, jako například distribuované databáze a~NoSQL databáze, včetně jejich vlastností, výhod a~nevýhod.

\section{Big data} \label{bigDataSection}
Definicí pro frázi Big data existuje několik. Jedná se o~termín použitý na soubory dat, které jsou příliš komplexní z~hlediska velikosti a~různorodosti, a~které je nemožné zpracovávat běžně používanými přístupy a~softwarovými nástroji v~rozumném čase.

Objem takových dat rychle roste. Vyskytují se v~mnoha odvětvích, například sběr informací o~počasí, sociální sítě, energetické a~telekomunikační společnosti, ekonomie a~finančnictví, či data z~kamer, měření z~různých senzorů apod. Z~toho plyne, že se jedná o~data různorodých typů, mohou být strukturovaná i~nestrukturovaná. Proto je potřeba existence různých technologií pro jejich uložení, zpracování, analýzu i~zobrazení.

\vspace{0.5cm}

\noindent Pojem Big data je často definován jako 4V z~anglických slov Volume, Velocity, Variety a~Value \cite{oracleBigData}:

\begin{itemize}
\item Volume -- Značí množství nebo velikost dat. Je vyžadováno zpracování vysokých objemů dat neznámých hodnot, například síťový provoz, data sesbírána ze senzorů apod.

\item Velocity -- Vyjadřuje rychlost z~hlediska vzniku dat a~potřeby jejich analýzy, některá vyžadují zpracování v~reálném čase. Nejdůležitější data se zapisují přímo do paměti, a~ne na disk, z~důvodu co nejrychlejšího zpracování.

\item Variety -- Znamená různorodost typů. Jedná se především o~nestrukturovaná data, například text, audio, video, data o~geografické poloze a~další. Jsou na ně kladeny velmi podobné požadavky jako na data strukturovaná – sumarizace, monitorování, důvěrnost \cite{oracleBigData}.

\item Value -- Data mají vlastní hodnotu, která musí být analyzována a~zjištěna. Nejedná se o~jednoduchý proces, je stále potřeba nových metod a~technik zpracování.
\end{itemize}

\begin{figure}[!h]
  \centering
  \includegraphics[width=15cm]{template-fig/big_data_exabytes.pdf}
  \caption{S~přibývajícími novými technologiemi se masivně zvyšuje růst dat a~přibývají nové typy \cite{rajeshBigData}.}
  \label{FIG_BigDataExabytes}
\end{figure}

\section{Distribuované databáze}
Distribuovaná databáze se skládá z~většího počtu samostatných databází, které mohou být geograficky rozmístěny na jiných pozicích. Jednotlivé uzly spolu komunikují přes počítačovou síť. Každý uzel je sám o~sobě databázový systém. DSŘBD neboli systém řízení distribuované báze dat (anglicky \texttt{Distributed Database Database Management System}) zajišťuje, že se distribuovaná databáze uživatelům jeví jako jedna jediná databáze. Data jsou fyzicky uložena na různých pozicích. Mohou být spravována rozdílnými SŘBD nezávisle na ostatních pozicích.

\vspace{0.5cm}

\noindent Systém řízení distribuované báze dat je centralizovaný systém s~těmito vlastnostmi 
\cite{distributedDBMS}:

\begin{itemize}
\item Umí vytvářet, získávat, upravovat a~odstraňovat distribuované databáze.

\item Zajišťuje důvěrnost a~integritu databází.

\item Periodicky synchronizuje databázi a~poskytuje mechanismy přístupu tak, aby se databáze uživatelům jevila transparentní.

\item Zajišťuje, že změna dat v~kterémkoliv uzlu se promítne i~v~ostatních uzlech.

\item Je využíván v~aplikacích, kde se předpokládá zpracování velkých objemů dat, ke kterým přistupuje současně mnoho uživatelů.

\item Je navržen pro heterogenní databázové platformy.
\end{itemize}

\begin{figure}[!h]
  \centering
  \includegraphics[width=15cm]{template-fig/DistributedDatabase.pdf}
  \caption{Schéma distribuované databáze a~současný přístup více zařízení k~ní \cite{distributedDBMSPic}.}
  \label{FIG_DistrDB}
\end{figure}

\subsection{Výhody}
\begin{itemize}
\item Rozšiřitelnost -- Pokud je potřeba databázový systém rozšířit do nových míst nebo přidat další uzly, stačí přidat nový(é) počítač(e) a~lokální data v~nové pozici, a~nakonec je připojit k~distribuovanému systému, bez jakéhokoliv přerušení funkcionality. Analogický postup je při odebrání uzlu.

\item Spolehlivost -- Když nějaký z~připojených uzlů selže, nepřestane distribuovaná databáze fungovat, sníží se maximálně výkon.

\item Ochrana (záloha) dat -- Při zničení jednoho uzlu a~smazání dat z~něj, mohou být stejná data zálohována i~na jiných uzlech.

\item Výkonnost -- Pokud jsou data efektivně distribuována, může být uživatelův požadavek uspokojen rychleji. Transakce mohou být také distribuované a~provedeny rychleji. 
\end{itemize}

\subsection{Nevýhody}
\begin{itemize}
\item CAP teorém -- Pojednává o~tzv. eventuální konzistenci (na rozdíl od absolutní konzistence u~databází splňujících vlastnosti ACID). Definuje, že distribuovaný systém může zajistit maximálně dvě z~těchto tří vlastností -- konzistence (angl. \texttt{Consistency}), dostupnost (angl. \texttt{Availability}) a~odolnost k~přerušení (angl. \texttt{Partition tolerance}). Je nutné si zvolit mezi konzistencí a~dostupností v~případě výpadku části sítě.

\item Integrita dat -- Data musí být průběžně synchronizována na více uzlech, aby na stejné dotazy nebyly z~různých uzlů vraceny rozdílné výsledky.

\item Komunikační režie -- I~zdánlivě jednoduchá operace může vyžadovat spoustu zbytečné komunikace.

\item Cena -- DSŘDB vyžaduje drahý a~složitý software ke koordinaci uzlů a~zajištění transparentnosti \cite{distributedDBMS}.

\item Mezi další patří -- složitost, zabezpečení a~řízení souběžného přístupu k~datům.
\end{itemize}

\begin{figure}[!h]
  \centering
  \includegraphics[width=15cm]{template-fig/DistributedDatabasesClassification.pdf}
  \caption{Distribuované databáze můžeme podle jejich vlastností dělit \cite{distributedDBMS}.}
  \label{FIG_DivDistrDB}
\end{figure}

\subsection{Rozdělení}
\subsubsection{Homogenní}
Všechny uzly používají identické SŘBD a~operační systémy. Uzly mají informace o~ostatních uzlech a~spolupracují při zpracování uživatelských požadavků. Homogenní distribuovaná databáze se uživateli navenek jeví jako jeden systém. Je jednodušší jej navrhnout a~spravovat. Homogenní distribuované databáze můžeme ještě dělit na autonomní a~neautonomní:

\begin{itemize}
    \item Autonomní -- Každá databáze je nezávislá, neexistuje žádný centrální uzel. Databáze jsou spravovány aplikací, a~pro předávání dat používají zasílání zpráv.
    
    \item Neautonomní -- Data jsou distribuována napříč homogenními uzly. O~aktualizaci a~správu dat se stará systém řízení distribuované báze dat, který běží na centrálním nebo také master uzlu.
\end{itemize}

\subsubsection{Heterogenní}
Uzly mohou mít rozdílné operační systémy a~SŘBD, které nejsou kompatibilní. Mohou také využívat rozdílná schémata (relační, objektově orientované, hierarchické, \ldots). Rozdílnost schématu je hlavním problémem při zpracování dotazu a~transakcí. Kvůli tomu je také složité dotazování \cite{wikiDBMS}. Heterogenní distribuované databáze můžeme rozdělit na federované (angl. \texttt{federated}) nebo multidatabázové.

Architekturami distribuovaných databází jsou centrální architektura, klient-server, peer-to-peer, a~multi-databázová architektura.

\section{Úložiště} \label{storage}
V~této sekci budou popsána strukturovaná a~nestrukturovaná data, jaký je mezi nimi rozdíl a~jaká jsou jejich úložiště.

\subsection{Strukturovaná data}
Strukturovanými daty jsou libovolná data, pro která lze sestavit datový model. Datový model přesně organizuje jednotlivé elementy dat a~specifikuje, jak spolu elementy souvisí, jaké mají vazby, jak budou uloženy, přístup k~nim, a~jak souvisí s~jednotlivými elementy reálného světa \cite{structData}. Typickým úložištěm strukturovaných dat je relační databáze. Pro čtení a~dotazování byl vytvořen dotazovací jazyk SQL.

\subsection{Nestrukturovaná data}
Jak už bylo zmíněno v~sekci \ref{bigDataSection}, Big data patří převážně mezi nestrukturovaná data. Data nemají přesně definovanou strukturu, neexistuje datový model, který by definoval jednotlivé dílčí elementy a~jejich vztahy. Mezi typické zástupce patří: videa, obrázky, audio, webové stránky, text, obsah e-mailové komunikace apod. Mezi vhodná úložiště mohou patřit disková úložiště, HDFS (\texttt{Hadoop Distributed File System}) a~NoSQL databáze.

\subsubsection{NoSQL databáze}
Pod zkratkou se nachází \texttt{non SQL} nebo také \texttt{Not only SQL}. Jedná se o~databázový koncept, ve kterém datové úložiště i~zpracování dat používají jiné prostředky než tabulková schémata tradiční relační databáze \cite{noSqlWiki}. NoSQL databáze jsou navrženy pro distribuovaná ukládání a~dotazování dat, souběžný přístup, a~manipulaci s~obrovským objemem dat. Mezi výhody patří: horizontální i~vertikální škálovatelnost, distribuovaný přístup, flexibilita schématu, dynamičnost. Nevýhodami však mohou být: absence standardizace, omezené schopnosti dotazování, konzistence \cite{noSqlIntro}.

\vspace{0.5cm}
\noindent NoSQL databáze mohou být rozděleny do čtyř kategorií \cite{noSqlOverview}:
\begin{itemize}
    \item Klíč-hodnota (angl. \texttt{Key-Value databases}) -- Jsou nejjednoduššími NoSQL úložišti. Každá položka v~databázi je uložena jako atribut (klíč) společně se svou hodnotou. Hodnota je typu \texttt{blob}, takže pouze aplikace dokáže hodnotu správně interpretovat. Databáze pouze ukládá binární data, kterým nerozumí. Klíč může být složený, např. z~několika částí, které lze použít jako ID do struktury a~nebo ID jejich položek. Klíče mohou být seřazené, což umožňuje efektivní procházení, nebo také organizovány do hierarchií. Zástupci jsou databáze \texttt{Riak} a~\texttt{Redis}.
    
    \item Dokumentové (angl. \texttt{Document databases}) -- Párují každý klíč se složitou datovou strukturou, nazývanou dokument. Představuje v~podstatě princip klíč-hodnota, ale hodnota je strukturovaná. Dokument může obsahovat mnoho rozdílných párů klíč-hodnota, párů klíč-pole, nebo dokonce vnořené dokumenty. Jsou vhodné pro dokumenty formátu XML a~JSON (BSON).
    Databáze dokáže interpretovat strukturovanou hodnotu (dokument), toho lze efektivně využít hlavně při dotazování. Dotazy mohou být i~složitější než přes klíče, např. pomocí \texttt{XPath}. Mezi zástupce patří \texttt{MongoDB} a~\texttt{CouchDB}.
    
    \item Grafové (angl. \texttt{Graph databases}) -- Jsou navrženy pro ukládání entit (uzly) a~jejich vztahů (hrany). Uzly i~hrany mohou mít svoje atributy. Jsou vhodné pro reprezentaci sítí a~jejich topologií, např. sociální či dopravní sítě, topologie počítačových sítí a~další \cite{noSqlPdb}.
    Zástupcem je \texttt{Neo4J}.
    
    \item Sloupcové (angl. \texttt{Column-oriented databases} / \texttt{Column family stores}) -- Data jsou organizována v~tabulkách. Tabulka má řádky jako v~relační databázi, ale u~řádku pak lze definovat sloupce s~hodnotami. Sloupce mohou být pro každý řádek různé (flexibilní schéma), i~různý počet (řídká pole). Sloupcové databáze jsou optimalizovány pro dotazování nad velkými objemy dat. Sloupce mohou být zobecněny na adresáře (anglicky \texttt{supercolumn}), kde potom řádek obsahuje kolekci supersloupců, a~z~nich každý obsahuje kolekci sloupců \cite{noSqlPdb}. Zástupci sloupcových databází jsou například \texttt{Cassandra} a~\texttt{HBase}.
\end{itemize}

\subsection{Srovnání relačních a~NoSQL databází}
Podle výše uvedených vlastností úložišť pro strukturovaná a~nestrukturovaná data můžeme vidět tyto rozdíly:

\begin{multicols}{2}

Relační databáze

\begin{itemize}
    \item Datový model je formalizovaný, databáze umožňuje definovat integritní omezení, kontroly, model reflektuje elementy reálného světa.
    
    \item S~daty lze provádět transformace v~podobě spojení, agregací, řazení apod.
    
    \item Kvůli podpoře transakcí a~ACID vlastností není úplně snadná škálovatelnost.
    
    \item Mají pevné schéma databáze. Vzniklé problémy po úpravách se musí řešit např. migračními skripty.
\end{itemize}

\columnbreak

NoSQL databáze

\begin{itemize}
    \item Jedná se o~nízkoúrovňové úložiště, kde ve většině případů databáze není schopna data interpretovat. Zajištění konzistence je ponecháno aplikaci. 
    
    \item Data lze dostat pouze v~podobě, v~jaké byla uložena.
    
    \item Jsou navrženy pro jednoduchou škálovatelnost.
    
    \item Mají dynamické schéma, které dovoluje definovat libovolnou strukturu a~provádět flexibilní úpravy.
\end{itemize}

\end{multicols}

\chapter{Návrh distribuovaného úložiště} \label{distrRepDesignChapter}
Tato kapitola se zabývá návrhem distribuovaného úložiště rozsáhlých digitálních forenzních dat. Bude popsána komunikace se systémem včetně aplikačního rozhraní, použité technologie, zvolené druhy úložišť a~také zpracování požadavků od klientské aplikace.

\section{Požadavky na systém}
Nejdůležitějším požadavkem je, aby systém byl distribuovaný, tzn. škálovatelný na více výpočetních uzlech. S~tím souvisí také výběr vhodných technologií.

Systém musí umožnit optimální přístup k~různým datům, jiný přístup bude pro strukturovaná data a~jiný pro nestrukturovaná. Z~forenzních digitálních dat proběhne implementace pro podporu \texttt{PCAP} souborů.

Posledním klíčovým požadavkem je umožnit přidávání podpory pro nové druhy digitálních forenzních dat přímo za běhu systému.

Ze sekce \ref{storage} vyplývá, že je vhodné využít NoSQL distribuovaných databází a~HDFS jako úložiště. Pro komunikaci s~klientem bude sloužit Kafka (společně se ZooKeeper). Všechny tyto technologie jsou distribuované a~ověřené pro použití v~Big data prostředích. Jak jednotlivé technologie fungují bude vysvětleno v~této kapitole.

\section{Aplikační rozhraní}
Aplikační rozhraní umožňuje klientovi komunikovat s~distribuovaným repositářem. Komunikace je založena na asynchronním zasílání zpráv. Systém repositáře nenabízí klientovi přímo žádné metody či funkce, které by klient mohl volat. Ovládání repositáře probíhá pomocí zaslání zprávy obsahující tzv. příkaz. Příkaz specifikuje typ operace a~typ dat. Podle typu příkazu je určeno, jak se daný příkaz zpracuje.

V~následující sekci bude vysvětleno, jak ovládání repositáře probíhá, jak vypadá zpráva, a~bude také uvedeno schéma celé komunikace jako příklad.

\subsection{Komunikace} \label{designCommunication}
Komunikace s~klientem, který chce do distribuovaného repositáře data uložit, nebo naopak z~něj nějaká data získat, probíhá pomocí zaslání zprávy tzv. \texttt{MQ broker}-u Kafka. Systém bude pracovat na principu požadavek -- odpověď, ale asynchronním způsobem. Zpráva požadavku obsahuje parametry -- atributy příkazu a~případně řetězec dat.

\vspace{0.5cm}
\noindent Název a~význam parametrů:

\begin{itemize}
    \item \texttt{command} -- Určuje typ příkazu, příklady příkazů mohou být \texttt{STORE\_PCAP} a~\texttt{LOAD\_PCAP}. Příkaz v~sobě ještě zapouzdřuje typ operace, které mohou být \texttt{SAVE} a~\texttt{LOAD}, a~také typ dat jako například \texttt{PCAP}, \texttt{Packet}, \texttt{BINARY}, \texttt{LOG} apod.
    
    \item \texttt{id} -- Povinný parametr, udává unikátní ID zprávy, aby klient potom dokázal identifikovat už zpracované příkazy.
    
    \item \texttt{awaitsResponse} -- Dvoustavová hodnota, jestli klient/odesilatel zprávy očekává od repositáře odpověď. Pokud je tento parametr zadán jako \texttt{True}, je nutné zadat také další parametr \texttt{responseTopic}.
    
    \item \texttt{responseTopic} -- Udává název fronty (angl. \texttt{topic}), ve které je odpověď na straně klienta očekávána.
    
    \item \texttt{errorTopic} -- Na straně distribuovaného úložiště se může vyskytnout chyba, například nedostupnost databáze, chyba při zpracování příkazu a~další. Tento parametr slouží pro zadání fronty, kam se budou zasílat chybová hlášení. Jedná se o~povinný parametr.
    
    \item \texttt{dataSource} -- Zdrojová data k~uložení lze zaslat dvojím způsobem. První z~nich je poslat data v~binární podobě přímo přes systém Kafka společně s~příkazem. Tento způsob lze využít pro data, jejichž velikost není příliš velká, protože se data načítají do paměti RAM. Pro velké objemy dat takový přístup není vhodný. Proto existuje ještě druhý způsob, a~to předat data přes distribuovaný souborový systém HDFS. Parametr \texttt{dataSource} obsahuje název úložiště v~podobě výčtové konstanty \texttt{Kafka} nebo \texttt{HDFS}, cestu k~souboru, pokud se jedná o~HDFS, a~také atribut \texttt{removeAfterUse} pro odstranění souboru po použití. Lze využít i~pro příkazy čtení dat ke způsobu předání výsledku -- přes HDFS nebo Kafku.
    
    \item \texttt{criterias} -- Představuje seznam kritérií pro dotazování. Tento parametr je vhodné vyplnit pouze při zasílání příkazu čtení.
\end{itemize}

\noindent Řetězec dat obsahuje vlastní data, která mají být na straně repositáře zpracována. Typy příkazů, a~v~podstatě typy operací s~typy dat lze libovolně přidávat.

\vspace{0.5cm}
\noindent Zpráva odpovědi nese tyto parametry:
\begin{itemize}
    \item \texttt{id} -- Jedná se o~unikátní ID zkopírované ze zprávy požadavku. Klient po přijetí odpovědi bude vědět, ke kterému požadavku odpověď patří.
    
    \item \texttt{responseTopic} -- Název výstupní fronty, do které je odpověď zaslána.
    
    \item \texttt{responseCode} -- Návratový kód odpovědi symbolizující jak operace dopadla. Analogie s~HTTP návratovými kódy, možnými hodnotami jsou: \texttt{OK(200)}, \texttt{BAD\_REQUEST(400)}, \texttt{UNSUPPORTED\_MEDIA\_TYPE(415)}, \texttt{INTERNAL\_SERVER\_ERROR(500)}.
    
    \item \texttt{status} -- Rezervovaný parametr pro status odpovědi.
    
    \item \texttt{detailMessage} -- Pokud se objeví při zpracování požadavku chyba, může být v~odpovědi odesláno, proč chyba nastala, nebo její přičina.
\end{itemize}

\begin{figure}[!h]
  \centering
  \includegraphics[width=14cm]{template-fig/Kafka_communication.pdf}
  \caption{Demonstrace komunikace -- zaslání zprávy požadavku pro uložení souboru PCAP. Klient zašle příkaz přes Kafku, příkaz je zpracován na straně distribuovaného repositáře, a~případně je odeslána odpověď klientovi. Můžeme si všimnout uvedených ID, jsou stejné -- klient zjistí, ke kterému příkazu odpověď patří.}
  \label{FIG_KafkaCommunication}
\end{figure}

\subsection{Kafka}
Apache Kafka je distribuovaný systém zpráv s~robustními frontami založený na mechanismu \texttt{publish-subscribe} umožňující přenášet vysoké objemy dat. Kafka zprávy jsou perzistentně uloženy na disku a~replikovány v~rámci clusteru kvůli prevenci ztráty dat. Systém Kafka je postaven na synchronizační službě ZooKeeper \cite{kafkaTutorialsPoint}. Výhody jsou:
\begin{itemize}
    \item Spolehlivost -- Kafka je distribuovaný systém, segmentovaný, replikovaný a~odolný proti chybám.
    
    \item Škálovatelnost -- Je možné připojit nové uzly do clusteru.
    
    \item Odolnost -- Zprávy jsou uloženy na disku.
    
    \item Výkon -- Vysoká propustnost pro obě akce \texttt{publish} a~\texttt{subscribe}, je zachován stabilní výkon i~při objemu zpráv v~terabytech.
\end{itemize}

\begin{figure}[!h]
  \centering
  \includegraphics[width=15cm]{template-fig/Kafka_architecture.pdf}
  \caption{Diagram zobrazující klíčové komponenty systému Kafka \cite{kafkaTutorialsPoint}.}
  \label{FIG_KafkaArchitecture}
\end{figure}

\noindent V~diagramu \ref{FIG_KafkaArchitecture} je fronta (angl. \texttt{topic}) konfigurována do tří oddílů (angl. \texttt{partition}). Pokud je faktor replikace fronty nastaven na hodnotu 3, Kafka vytvoří tři identické repliky každého oddílu a~umístí je do clusteru. Každý prostředník (angl. \texttt{broker}) ukládá jeden nebo více těchto oddílů za účelem vyvažování zátěže. Více producentů, respektive konzumentů, může zároveň vydávat (angl. \texttt{publish}), resp. odebírat, (angl. \texttt{subscribe}) zprávy \cite{kafkaTutorialsPoint}.

\vspace{0.5cm}
\noindent Hlavní komponenty systému Kafka z~diagramu \ref{FIG_KafkaArchitecture}:
\begin{itemize}
    \item Fronta -- Jedná se o~proud zpráv patřící k~příslušné kategorii. Data jsou uložena ve frontách. Fronty jsou rozděleny do oddílů.
    
    \item Oddíl -- Fronty mohou mít mnoho oddílů, tak aby zvládaly zpracování libovolného množství dat.

    \item Offset oddílu (angl. \texttt{Partition offset}) -- Každá zpráva v~oddílu má unikátní sekvenci ID nazývanou offset.

    \item Replika oddílu -- Je pouhou zálohou oddílu. Repliky nejsou využívány ke čtení nebo zápisu dat, slouží pouze jako prevence před ztrátou dat.
    
    \item Prostředník -- Jednoduchý systém zodpovědný za správu dat v~oddílech, resp. frontách. Prostředníci slouží k~balancování zátěže.
    
    \item Kafka Cluster -- Pokud existuje víc než jeden prostředník, pak se systém nazývá cluster. Cluster může být rozšířen bez prodlev o~další prostředníky.
    
    \item Producent -- Je odesílatel zprávy do jedné nebo více Kafka front. Producenti posílají data prostředníkům. Pokaždé když producent pošle zprávu prostředníkovi, prostředník přidá zprávu na konec oddílu. Producent nečeká na žádná potvrzení, posílá zprávy tak rychle, jak jen prostředník dokáže přijímat.
    
    \item Konzument -- Čte data od prostředníka(ů). Odebírá z~jedné nebo více front a~konzumuje zprávy získáním dat od prostředníků.
\end{itemize}

\section{Úložiště}
Tato sekce se zaměřuje na úložiště, kde budou digitální forenzní data uchována. Můžeme je rozdělit na strukturovaná a~nestrukturovaná.

\subsection{Strukturovaná data}
V~souvislosti se systémem repositáře se obecně jedná o~data, která mohou být rozdělena na menší části při zachování možnosti interpretace, a~mohou být efektivně serializována pro uložení. Mezi strukturovaná data můžeme zařadit například soubory formátu PCAP obsahující síťovou komunikaci. Tyto soubory lze rozparsovat na jednotlivé segmenty pakety. Pakety lze potom serializovat na pole bytů a~uložit do NoSQL databáze. Pro strukturovaná data byla vybrána databáze Cassandra.

\subsubsection{Cassandra}
Jedná se o~zástupce sloupcových NoSQL databází. Výhodami jsou předně: škálovatelnost, odolnost proti chybám, rychlost, distribuovanost, konzistence a~podpora transakcí. Cassandru využívají i~světoznámé společnosti Facebook, Twitter, Cisco, ebay, Twitter, Netflix a~další. Cílem Cassandry je zvládat vysoké objemy dat napříč mnoha uzly. Data jsou pak distribuována na všech uzlech clusteru. Uzly lze libovolně přidávat. Každý uzel je nezávislý a~zároveň propojený s~ostatními. Každý uzel v~clusteru se může podílet na požadavcích čtení či zápisu nezávisle na tom, kde jsou data skutečně uložena. Když uzel selže, požadavky čtení a~zápisu mohou být obslouženy jinými uzly sítě \cite{cassandraTutorialsPoint}.

\subsection{Nestrukturovaná data}
Pro uchování nestrukturovaných dat typu například audio, video, logů, a~obecně binárních dat bude sloužit distribuovaný souborový systém HDFS. Taková data mohou mít velký objem, a~bylo by plýtvání výkonem provádět jejich serializaci nebo rozdělování na části při ukládání do NoSQL databází.

\subsubsection{Hadoop a~HDFS}
Distribuovaný souborový systém HDFS patří pod projekt \texttt{Apache Hadoop}, který je navržen pro ukládání a~zpracování obrovského množství dat v~distribuovaném prostřední napříč mnoha počítači. Počítá se škálovatelností od jednoho serveru po tisíce strojů, kde každý z~nich nabízí lokální úložiště a~výpočetní zdroje \cite{hadoopTutorialsPoint}.

\vspace{0.5cm}
\noindent Platforma Hadoop zahrnuje tyto moduly:

\begin{itemize}
    \item \texttt{Hadoop Common} -- Knihovny a~pomocné nástroje požadované ostatními Hadoop moduly. Poskytují abstrakce souborového a~operačního systému potřebné pro jazyk Java, a~skripty nutné pro spuštění Hadoop-u.
    
    \item \texttt{Hadoop YARN} -- Jedná se o~framework pro plánování distribuovaných úloh a~správu zdrojů.
    
    \item \texttt{HDFS} -- Distribuovaný souborový systém poskytující vysokou propustnost přístupu k~aplikačním datům, škálovatelnost, odolnost proti chybám a~efektivní správu zdrojů.
    
    \item \texttt{Hadoop MapReduce} -- Systém pro paralelní zpracování obrovského množství vstupních dat. Tento modul je pro systém distribuovaného úložiště zbytečný.
\end{itemize}

\noindent Kromě výše uvedených modulů existují i~další pomocné nástroje:  \texttt{Apache Spark}, \texttt{Apache HBase} -- distribuovaná databáze, \texttt{Apache Hive} -- nástroj pro dolování dat nad platformou Hadoop, \texttt{Apache Pig} atd.

\begin{figure}[!h]
  \centering
  \includegraphics[width=15cm]{template-fig/HDFSArchitecture.pdf}
  \caption{Architektura HDFS \cite{apacheHDFSGuide} -- datové uzly jsou uspořádány do \texttt{rack}-ů, které se nachází v~jedné lokalitě, což zajišťuje rychlejší propojení uzlů. Bloky jsou replikovány mezi odlišné uzly.}
  \label{FIG_HDFSArchitecture}
\end{figure}

\noindent HDFS je virtuální souborový systém vybudovaný nad běžnými souborovými systémy jednotlivých uzlů. Řeší problém nalezení úložiště a~přístupu k~datům, nikoliv fyzické uložení v~uzlu. Byl navržen pro sekvenční přístup k~souborům, nikoliv náhodný \cite{hadoopPdi}.

HDFS používá architekturu typu \texttt{master/slave}. Master se skládá z~jednoho uzlu nazývaného \texttt{NameNode}, který se stará o~správu metadat a~jmenného prostoru souborového systému. Dále reguluje přístup k~souborům a~provádí operace typu otevření, zavření, přejmenování souborů a~adresářů. Protože je NameNode pouze jeden, měl by být spolehlivý a~výkonný, při jeho výpadku způsobí poruchu systému (jde o~tzv. \texttt{single point of failure}). Uzlů typu slave může být více, jsou nazývány datové uzly (angl. \texttt{DataNodes}), a~ukládají data. Soubor je rozdělen do několika bloků (typicky po 64 nebo 128 MB), a~každý blok souboru je nezávisle replikován v~několika datových uzlech slave. Bloky jsou uloženy v~lokálním souborovém systému na datových uzlech. Datové uzly jsou také zodpovědné za zpracování požadavků čtení a~zápisu od klientů. NameNode se stará o~mapování bloků datovým uzlům, sleduje počet replik jednotlivých bloků. Pokud se nějaká replika ztratí vinou selhání datového uzlu, je vytvořena nová replika bloku \cite{hadoopHortonworks}.

HDFS je implementován v~jazyce Java, na každém stroji s~nainstalovanou Javou může běžet NameNode nebo DataNode software. Typicky při nasazení existuje jeden stroj s~běžícím NameNode, na dalších strojích potom běží datové uzly (lze ovšem najít i~scénáře, kde na jednom stroji běží více datových uzlů). Důležité je, že uživatelská data nikdy neprochází přes NameNode \cite{apacheHDFSGuide}.

\subsection{Metadata} \label{metadata}
V~rámci zpracování příchozí zprávy do repositáře informující o~operaci uložení, by bylo vhodné provést předzpracování dat za účelem vhodnější indexace a~rychlejšího nalezení pro budoucí operace čtení. Jednalo by se tak o~mechanismus podobný například pamětem cache. Uvažme následující scénář pro podrobnější vysvětlení.

Do repositáře bylo v~průběhu několika dnů uloženo mnoho milionů paketů, které obsahovaly síťovou komunikaci mezi několika komunikujícími stranami. Data paketů jsou uložena v~serializované podobě v~NoSQL databázi. Na úrovni databáze nedávají taková data žádný význam, pouze aplikace je dokáže správně interpretovat jako pakety. Po několika dnech by uživatel rád zjistil podrobnější informace o~komunikaci mezi uzly A~a~B. Nezbývalo by mu nic jiného, než všechna data z~NoSQL databáze načíst na aplikační úrovni a~analyzovat paket po paketu, aby zjistil minimálně IP adresy zdroje a~cíle. Takový způsob by byl velmi pomalý a~neefektivní.

Následně uvažme, jak by vypadal postup pro zjištění informací o~komunikaci mezi uzly A~a~B, kdyby byla k~dispozici cache, či paměť metadat. Cache by mohla uchovávat základní informace o~dříve uložených paketech v~jednotně definované struktuře. Mezi tyto informace by patřily -- zdrojová a~cílová IP adresa, zdrojová a~cílová MAC adresa, typ protokolu, časové razítko a~další. Co je však důležité, u~těchto informací by bylo uvedeno ID záznamu z~NoSQL databáze, kde je uchován celý paket. Pro zjištění podrobnějších informací by uživatel mohl načíst pouze ty pakety, které jsou pro něj relevantní.

Předzpracování dat je výhodné před jejich uložením, protože v~kontextu provádění aplikace jsou data interpretovatelná. Výtah základních informací z~nich nezpůsobí propad výkonu. Naopak se výkon zvýší pro případné operace čtení a~hledání.

Výše uvedený princip by se dal zobecnit pro libovolný typ forenzních digitálních dat. Tak by došlo k~vytvoření tzv. registru, který by i~mimo jiné informoval, co je jak a~kde uloženo. Vhodnou strukturou pro uložení těchto metadat může být například formát XML nebo JSON. Z~toho vyplývá použití dokumentové NoSQL databáze jako například MongoDB. MongoDB umožňuje dotazování nad dokumenty podle různých kritérií. Současně se také jedná o~distribuovanou databázi, která může navíc běžet na jiném uzlu než Cassandra. Flexibilita MongoDB je vhodná pro správu metadat, zvlášť když bude do repositáře potřeba přidávat nové druhy dat.

\subsubsection{MongoDB}
MongoDB je multiplatformní, dokumentově orientovaná databáze poskytující vysoký výkon a~jednoduchou škálovatelnost. Pracuje na principu kolekcí, které nevyžadují schéma. Kolekce je skupina dokumentů, a~je ekvivalentem SŘBD tabulek. Dokumenty v~kolekcích mohou mít dynamická schémata a~rozdílné atributy. Dynamické schéma znamená, že dokumenty ve stejné kolekci nemusí mít stejnou strukturu atributů. Počet atributů a~obsah dokumentu se může mezi dokumenty lišit. Dokument je množina párů klíč-hodnota \cite{mongoDBTutorialsPoint}.

Relační databáze má určité schéma skládající se z~tabulek a~vztahů mezi nimi. Koncept vztahu je v~MongoDB  řešen jinak. Existují dva mechanismy umožňující aplikaci reprezentovat vztahy -- reference a~vnořené dokumenty. Reference uchovávají vztahy mezi daty vložením odkazů (referencí) z~jednoho dokumentu do druhého. Aplikace může díky odkazu přistoupit k~příslušným datům. Vnořené dokumenty zachycují vztahy mezi daty ukládáním příslušných dat přímo do jednoho dokumentu. Namísto atributu dokumentu může být uložen i~jiný dokument. Výhoda tohoto modelu je, že aplikace získá všechna data v~jedné databázové operaci \cite{mongoDBDataModelingIntro}.

\section{Jádro distribuovaného úložiště}
V~předchozích sekcích byla představena komunikace s~repositářem, jak vypadají příkazy a~jakým způsobem jsou posílána data. Následně byly popsány možnosti ukládání. Tato sekce se zaměřuje na jádro distribuovaného repositáře, převážně na zpracování příkazů a~manipulaci s~databázemi.

Přijetí příkazu zajišťuje konzument zpráv. Konzument se v~krátkých časových intervalech dotazuje na zprávy z~Kafka fronty. Po přijetí zprávy dojde k~přečtení příkazu určeného typem operace a~typem dat společně s~dodatečnými parametry uvedenými v~\ref{designCommunication}. Na základě příkazu dojde k~výběru konkrétní obsluhy (tzv. \texttt{handler}-u), která má za úkol zpracování příkazu. Může se jednat o~uložení dat, o~načtení dat podle zadaných parametrů, přečtení metadat apod. Handler ukrývá všechny potřebné operace, které mají proběhnout při zpracování příkazu. Mimo jiné se jedná i~o~správu metadat zmíněnou v~sekci \ref{metadata}. Při implementaci budou objektu obsluhy nastaveny potřebné závislosti pro řešení databázových operací pro daný typ dat. Každý typ úložiště (souborový systém nebo NoSQL databáze) může mít jiné rozhraní přístupu.

Důležitým požadavkem je, aby úložiště umožňovalo přidávání podpory pro nové druhy forenzních dat za běhu. Tento požadavek je implicitně zajištěn systémem Kafka, který každou přijatou zprávu zapíše na disk a~zpráva tam zůstává, dokud ji konzument úspěšně nezpracuje. V~tom případě lze systém repositáře zastavit, ale Kafka zprávy bude pořád přijímat. Mezitím může proběhnout do-implementování nové funkcionality pro jiný druh forenzních dat, provést kompilaci, nasazení a~spuštění systému. Po spuštění se konzument začne dotazovat Kafky na nové nepřijaté zprávy.

\chapter{Implementace} \label{chapter_impl}
Tato kapitola se zabývá implementací distribuovaného úložiště, dekompozicí systému, technickými detaily, komunikací s~databázemi, a~architekturou systému.

\section{Dekompozice do modulů}
Repositář je komplexní distribuovaný systém založen na frameworku Spring, sestávající z~několika modulů. V~této sekci je uvedeno, jak byl systém dekomponován do modulů a~jaké knihovny byly zvoleny. Pro správu závislostí a~sestavení aplikace byl zvolen nástroj \texttt{Maven}. Pro přehled byly využity tyto knihovny a~frameworky -- \texttt{Spring Boot}, \texttt{Spring Data}, \texttt{Spring Kafka}, \texttt{Spring Hadoop}, \texttt{Pcap4J}, a~samozřejmě ovladače pro jednotlivé databáze.

Jedná se o~dvě Spring Boot aplikace -- \texttt{DistributedRepository} a~\texttt{ProducerDemo}, které komunikují pomocí komunikačního rozhraní implementovaného v~modulu \texttt{Communication}. Přenos zpráv zajišťuje projekt Spring Kafka. Aplikace DistributedRepository má přístup k~oběma databázím Cassandra a~MongoDB díky modulu \texttt{Persistence} obsahujícím mimo jiné projekt Spring Data, a~také k~HDFS pomocí projektu Spring Hadoop. K~HDFS má přístup i~klientská aplikace ProducerDemo.

\begin{figure}[!h]
  \centering
  \includegraphics[width=12.55cm]{template-fig/Architecture.pdf}
  \caption{Schéma klíčových modulů a~závislostí systému.}
  \label{FIG_Architecture}
\end{figure}

\subsection{Pcap4J} \label{pcap4j}
Jedná se o~knihovnu pro jazyk Java pro zachytávání, konstruování a~odesílání paketů. Knihovna je stále ve vývoji. Pcap4J pracuje nad nativní knihovnou (\texttt{libpcap}, \texttt{WinPcap}, nebo \texttt{Npcap} v~závislosti na operačním systému) přes JNA (\texttt{Java Native Access})
\footnote{https://github.com/java-native-access/jna}
a~poskytuje aplikační rozhraní pro jazyk Java. Mimo výše uvedené činnosti dokáže pracovat s~PCAP soubory, vytvářet a~parsovat je na jednotlivé pakety. Každý paket implementuje rozhraní \texttt{Packet}. Toto rozhraní nabízí mimo jiné dvě klíčové metody \texttt{contains} a~\texttt{get}. Metoda \texttt{contains} slouží ke kontrole, jestli je paket konkrétního typu, který chceme získat. Metoda má jako parametr třídu, které je paket typem, hlavička metody potom vypadá:

\begin{lstlisting}[language=Java]
    boolean contains(Class<T> clazz)
\end{lstlisting}

\noindent Ke konkrétnímu typu paketu, se přistupuje pomocí reflexe voláním metody:

\begin{lstlisting}[language=Java]
    T get(Class<T> clazz)
\end{lstlisting}

\noindent Například lze získat IP paket následujícím voláním:

\begin{lstlisting}[language=Java]
    IPv4Packet ipv4Packet = ethernetPacket.get(IPv4Packet.class);
\end{lstlisting}

\noindent Návratová hodnota metody \texttt{get} je objekt třídy uvedené v~parametru. Před voláním \texttt{get} je vhodné zkontrolovat typ pomocí metody \texttt{contains}. Z~konkrétního paketu už lze získávat potřebné informace, v~případě IP paketu údaje z~hlavičky jako zdrojová a~cílová IP adresa, verze protokolu apod. Analogicky lze postupovat i~v~případě ostatním typů paketů, Z~TCP paketu lze získat údaje o~portech, sekvenční čísla, kontrolní součet a~další.

Knihovna reflektuje zapouzdření, které spočívá ve vložení protokolové datové jednotky (anglicky \texttt{Protocol Data Unit}) vyšší vrstvy do protokolové jednotky nižší vrstvy. Takže ethernetový paket může být současně i~IP paketem a~podobně.

\begin{figure}[!h]
  \centering
  \includegraphics[width=15cm]{template-fig/Pcap4JExample.pdf}
  \caption{Schéma znázorňující výše uvedený příklad pro manipulaci s~pakety \cite{gitPcap4J}.}
  \label{FIG_Pcap4JExample}
\end{figure}

\subsection{Spring, Spring Boot a~Spring projekty} \label{springProjects}
Spring je velmi populární framework pro jazyk Java umožňující vytvářet webové a~enterprise aplikace. Věnuje se mnoha obecným principům a~problémům jako jsou například \texttt{dependency injection}, konfigurace, aspektově orientované programování, ORM, validace, bezpečnost, testování, integrace s~jinými frameworky atd. V~současné době pod něj spadají desítky projektů, každý zaměřený na jiný aspekt \footnote{https://spring.io/docs/reference}.

Spring poskytuje tři způsoby konfigurace -- pomocí XML, anotací a~konfigurace přímo v~Java. S~rozšiřující se funkcionalitou se zvyšuje komplexita a~i~konfigurace se stává obtížná a~náchylná k~chybám. Z~důvodu lepšího způsobu konfigurace byl vyvinut Spring Boot. Spring Boot přichází s~principem auto-konfigurace, ponechává však možnost předefinovat výchozí nastavení. Klíčovými vlastnostmi jsou \cite{whySpringBoot}:

\begin{itemize}
    \item Jednoduchá správa závislostí -- Pokud chceme použít Spring Boot k~běhu aplikace, je potřeba importovat \texttt{spring-boot-starter-parent} jako modulovou závislost. Existují další \texttt{Spring Boot Starter} závislosti, které se hodí pro určitý typ nebo aspekt vyvíjené aplikace. Existují např. \texttt{Test Starter}, \texttt{Web Starter}, \texttt{Security Starter}, \texttt{Data JPA Starter}, \texttt{AOP Starter} atd. Pokud chceme vyvíjet např. webovou aplikaci, Web Starter poskytne všechny potřebné závislosti zahrnující MVC modul, validační API, prostředky k~serializaci dat atp. Webová aplikace typicky potřebuje pracovat s~databází -- Data JPA Starter poskytne všechny potřebné závislosti zahrnující transakční API, \texttt{Hibernate} knihovny, ORM implementaci atd.
    
    \item Auto-konfigurace -- Nejenže Starter Web poskytne potřebné závislosti, ale proběhne konfigurace běžně používaných objektů tříd \texttt{ResourceHandlers}, \texttt{MessageSource} atd. výchozími hodnotami. Analogicky proběhne konfigurace objektů nutných k~používání JPA -- \texttt{DataSource}, \texttt{TransactionManager} a~\texttt{EntityManagerFactory}. Uživatel tyto objekty sám nevytváří, o~jejich vytvoření se postará Spring Boot na základě poskytnutých údajů v~konfiguračním souboru \texttt{application.properties} (příklad konfigurace aplikace uveden v~příloze \ref{configuration}). Spring Boot tedy podle zdrojů uvedených v~\texttt{classpath} provádí konfiguraci celé aplikace.
    
    \item Podpora zabudovaného kontejneru -- Pokud vyvíjíme webovou aplikaci, která bude běžet v~nějakém kontejneru typu \texttt{Tomcat}, není potřeba provádět žádná nasazení do externího kontejneru. Kontejner je při kompilaci automaticky stažen spolu s~ostatními závislostmi a~je zabudovaný, takže aplikaci stačí pouze spustit a~Spring Boot se postará o~nasazení aplikace do zabudovaného kontejneru. Samozřejmě lze zvolit i~jiný typ kontejneru, např. \texttt{Jetty} apod.
\end{itemize}

\noindent Spring Boot umožňuje vytvářet tzv. \texttt{beans} přímo v~Java kódu, bez použití XML konfiguračních souborů. Každou bean lze vytvořit pomocí anotace \texttt{@Bean}, např.

\begin{lstlisting}[language=Java,frame=tb,basicstyle={\small\ttfamily}]
@Configuration
public class ParserBeans {
    @Bean
    public PcapParser<PcapPacket> pcapParser() {
        return new ParserImpl();
    }
}
\end{lstlisting}

\noindent Použití vytvořené bean je velmi jednoduché pomocí anotace \texttt{@Autowired}:

\begin{lstlisting}[language=Java,frame=tb,basicstyle={\small\ttfamily}]
@Autowired
private PcapParser<PcapPacket> pcapParser;
\end{lstlisting}

\noindent Uživatel tedy definoval bean v~konfigurační třídě označené anotací \texttt{@Configuration}, a~tato instance je pak dodána principem dependency injection.

\subsubsection{Spring Kafka} \label{springKafka}
Projekt Spring Kafka aplikuje klíčové koncepty Spring-u pro vývoj systémů založených na platformě Kafka. Poskytuje šablonu jako vysokoúrovňovou abstrakci pro zasílání zpráv \cite{springKafka}. Velkým přínosem je výše zmíněná auto-konfigurace ze zadaných parametrů, která umožňuje okamžité použití komponent bez vytváření instancí uživatelem.

Mezi nejdůležitější třídy patří \texttt{KafkaTemplate}, která zapouzdřuje mnoho metod pro odeslání zpráv do Kafka front. Podporuje asynchronní i~synchronní odesílání. Použití této šablony lze vidět ve třídě \texttt{ResponseProducer} z~diagramu tříd \ref{FIG_CommunicationClassDiagram}.

Zprávy mohou být přijímány pomocí zvoleného kontejneru \texttt{MessageListenerContainer}, který poskytuje implementaci tzv. \texttt{Message Listener}-u nebo je označen pomocí anotace \texttt{@KafkaListener}. Existují 2 implementace kontejneru -- \texttt{KafkaMessageListenerContainer} (aktuálně použitá implementace v~systému repositáře), kde jsou přijímány všechny zprávy ze všech front a~oddílů v~jednom vláknu; a~\texttt{ConcurrentMessageListenerContainer}, který deleguje zpracování 1 nebo více kontejnerům, což poskytuje vícevláknový odběr zpráv a~tudíž i~vícevláknové zpracování \cite{springKafka}, více v~\footnote{https://docs.spring.io/spring-kafka/docs/2.1.6.BUILD-SNAPSHOT/reference/html/\_reference.html}. Lze také nastavit různé filtry a~vzorce pro přijímané zprávy, a~rozdělit tak příjem zpráv podle jejich struktury jiným objektům.

\subsubsection{Spring Hadoop}
Další z~projektů, které patří pod Spring, je Spring Hadoop, zjednodušující použití Hadoop API pro Javu. Přináší zase výše zmíněný jednotný konfigurační model usnadňující vývoj systémů postavených na platformě Hadoop, využívající HDFS, paradigma MapReduce, Hive a~Pig. Poskytuje také integraci s~jinými projekty ze Spring ekosystému jako například \texttt{Spring Integration} a~\texttt{Spring Batch}. Podporuje tvorbu Hadoop aplikací, které jsou konfigurovány principem dependency injection a~spuštěny jako standardní Java aplikace nebo pomocí nástrojů Hadoop pro příkazovou řádku.
Velmi jednoduše lze integrovat se Spring Boot pro zjednodušení připojení k~HDFS za účelem manipulace s~daty \cite{springHadoop}. Jedná se o~komplexní systém obsahující obrovské množství dalších nástrojů, podsystémů a~nastavení, které ovšem překračují použití v~distribuovaném úložišti, více lze nalézt na referenčních webových stránkách projektu Spring Hadoop \footnote{https://docs.spring.io/spring-hadoop/docs/2.5.1.BUILD-SNAPSHOT/reference/html/}.

Pro účely distribuovaného repositáře byla využita převážně možnost propojení s~HDFS. Přistupovat k~HDFS lze obecně několika způsoby -- použít Java API \footnote{https://hadoop.apache.org/docs/r2.7.3/api/org/apache/hadoop/fs/FileSystem.html} (nutno stále kontrolovat výjimky a~ošetřovat chybové stavy), nebo souborový systém ovládat pomocí příkazové řádky nástrojem \texttt{hadoop} \footnote{https://hadoop.apache.org/docs/r2.7.3/hadoop-project-dist/hadoop-common/FileSystemShell.html} mimo Java aplikaci. Oba způsoby nejsou uživatelsky přívětivé. Spring Hadoop propojuje tyto dva způsoby skrze intuitivní jednoduché Java API \cite{springHadoopReference}.

HDFS nabízí tři API, jejichž vlastnosti znázorňuje tabulka \ref{HDFSApi}.
\begin{table}[h!]
    \centering
    \begin{tabular}{| l | l | l | l | l |}
    \hline
    File System   &   Comm. Method   &   Scheme / Prefix &  Read / Write &   Cross Version \\ \hline
    HDFS & RPC & \texttt{hdfs://} & Read / Write & Same HDFS v. only \\ \hline
    HFTP & HTTP & \texttt{hftp://} & Read only & Version independent \\ \hline
    WebHDFS & HTTP (REST) & \texttt{webhdfs://} & Read / Write & Version independent \\ \hline
    \end{tabular}\par
    \bigskip
    \caption{Druhy API, které HDFS poskytuje, převzato z~referenční dokumentace \cite{springHadoopReference}.}
    \label{HDFSApi}
\end{table}

\noindent Pro účely distribuovaného úložiště bylo zvoleno první API, tzv. HDFS, založené na RPC volání -- tento způsob vyžaduje, aby klient i~Hadoop cluster běželi na stejné verzi (rozdílné verze způsobí problémy v~serializaci). Další alternativou by bylo API WebHDFS, které ovšem vyžaduje další konfiguraci, a~přenos pomocí HTTP přináší režii navíc ve formě zpomalení ukládání a~čtení dat.
API HFTP v~tomto případě využít nelze, protože podporuje pouze čtení.

Praktickým nástrojem poskytovaným distribucí Hadoop je klient příkazové řádky, přes kterého lze spouštět příkazy podobné těm linuxovým přímo nad HDFS -- existenci, odstranění, kopírování, přesouvání souborů, nebo nastavení přístupových práv. Tento nástroj je dostupný pouze přes příkazovou řádku, což stěžuje použití přímo z~Java aplikace. Spring Hadoop poskytuje plně zabudovanou funkcionalitu výše zmíněného nástroje uvnitř třídy \texttt{FsShell}, která zrcadlí většinu příkazů dostupných z~příkazové řádky (metody typu \texttt{chmod}, \texttt{cp}, \texttt{copyFromLocal}, \texttt{get}, \texttt{ls}, \texttt{mkdir}, \texttt{put}, \texttt{rm}, atd) \cite{springHadoopReference}. Pomocí této třídy jsou prováděny veškeré operace s~HDFS.

\section{Úložiště}
Jak už bylo uvedeno v~kapitole \ref{distrRepDesignChapter}, úložiště je tvořeno NoSQL databázemi Cassandra a~MongoDB, a~distribuovaným souborovým systémem HDFS. Zatímco předešlá kapitola jen nastínila vlastnosti těchto úložišť, zde budou vysvětleny technické detaily a~práce s~nimi.

\subsection{Cassandra} \label{cassandra}
Schéma databáze Cassandra je aktuálně velmi jednoduché. Nejzevnější úroveň tvoří tzv. \texttt{Keyspace} představující kontejner tabulek. Keyspace svými atributy udává replikační faktor (angl. \texttt{replication factor}), strategii umísťování replik (angl. \texttt{replica placement strategy}), a~třídy sloupců (angl. \texttt{column families}). Aktuální nastavení keyspace vypadá následovně:

\vspace{0.5cm}
\texttt{CREATE KEYSPACE structured\_data WITH replication = }

\texttt{\string{ 'class':'SimpleStrategy', 'replication\_factor':1 \string} }

\vspace{0.5cm}
\noindent Je použita strategie \texttt{SimpleStrategy}, vhodná pouze pro jedno sdružení počítačových uzlů (\texttt{rack}). Není optimální pro současné použití mnoha datovými centry, k~tomu slouží strategie \texttt{NetworkTopologyStrategy}. Replikační faktor vyjadřuje počet strojů v~clusteru, které obdrží stejnou kopii dat. Zde nastaveno na hodnotu 1.

Schéma tabulky pro ukládání paketů je taktéž velmi jednoduché. Tabulka obsahuje pouze primární klíč ID a~hodnotu paketu v~binární podobě. Struktura tabulky:

\vspace{0.5cm}
\texttt{packet (
	id timeuuid PRIMARY KEY,
	packet blob
)}

\subsubsection{Asynchronní dotazy}
Distribuovaný repositář komunikuje s~databází asynchronně z~důvodu co největší propustnosti a~rychlosti. Asynchronní komunikace je umožněna díky třídám a~metodám ovladače pro jazyk Java od společnosti DataStax, který je stále ve vývoji \footnote{https://github.com/datastax/java-driver}. Tento ovladač používá asynchronní architekturu. Takový způsob komunikace dovoluje klientské aplikaci ukládat data a~provádět nad nimi dotazy neblokujícím způsobem, díky tzv. \texttt{Future} instancím \cite{asyncQueriesCassandra}.

\begin{figure}[!h]
  \centering
  \includegraphics[width=15cm]{template-fig/CassandraAsyncQueries.pdf}
  \caption{Sekvenční diagram znázorňující jednotlivá volání metod při vykonávání asynchronního dotazu do databáze Cassandra \cite{asyncQueriesCassandra}.}
  \label{FIG_CassandraAsyncQueries}
\end{figure}

\noindent Kromě zaslání dotazu do databáze, ovladač registruje interní obsluhu v~podobě objektu \texttt{ResponseHandler}, který zpracuje odpověď dotazu, až bude k~dispozici. Po zaregistrování obsluhy je předáno řízení vykonávání volajícímu programu společně s~objektem třídy \texttt{ResultSetFuture}, pomocí kterého klient dokáže získat výsledek dotazu a~dále s~ním pracovat.
Až databáze dotaz dokončí a~vrátí odpověď, ovladač avizuje ResponseHandler (obecně může být zaregistrováno mnoho takových obsluh pro různé dotazy, párování je provedeno pomocí unikátního ID \texttt{streamId}, které bylo zasláno s~dotazem). Obsluha třídy ResponseHandler dokončí volání upozorněním objektu třídy ResultSetFuture.
Klientský kód získá výsledek dotazu provedením metody \texttt{get} nad objektem ResultSetFuture. Volání této metody je blokující, pokud ještě nebyl nastaven výsledek objektu ResultSetFuture \cite{asyncQueriesCassandra}.

Čekat na výsledek blokujícím způsobem není efektivní, proto existuje i~způsob bez blokování. V~takovém případě musí klient k~objektu ResultSetFuture zaregistrovat svůj tzv. \texttt{callback}, který bude vykonán, až bude výsledek k~dispozici.
Lze zvolit i~jiné vlákno pro jeho vykonání, aby aktuálně běžící kód nemusel být pozastaven. To lze například pomocí knihovny \texttt{Guava} od Google a~jejich tříd \texttt{Futures} a~\texttt{FutureCallback}.

\noindent Ovladač od DataStax je obecně celý asynchronní, uvnitř jeho synchronních metod je zavolána asynchronní verze, a~pak okamžitě blokující metoda get. Ovladač umožňuje paralelně provádět pouze omezený počet dotazů. Tento počet je udán vnitřními parametry \texttt{Cluster} objektu (více detailních informací lze nalézt na referenčních www stránkách ovladače v~sekci \texttt{Connection pooling} \footnote{https://docs.datastax.com/en/developer/java-driver/2.1/manual/pooling/}):

\begin{itemize}
    \item \texttt{maxRequestsPerConnection} -- Udává maximální počet požadavků na jedno připojení.
    
    \item \texttt{maxConnectionsPerHost} -- Udává maximální počet připojení na uzel.
\end{itemize}

\noindent Počet paralelních připojení do databáze Cassandra je v~systému limitován semaforem. Jinak by vždy při vyčerpání dostupných připojení docházelo k~selhání ve formě výjimky \texttt{NoHostAvailableException}. Při každém dotazu do databáze, čtení nebo zápis, tedy dojde k~uzamčení semaforu, při dokončení operace (či při chybě) zase k~odemknutí semaforu. Semafor byl nastaven na počet přístupů daných výrazem:

\vspace{0.5cm}
\texttt{maxConnectionsPerHost * maxRequestsPerConnection}

\vspace{0.5cm}
\noindent Tímto přístupem je tedy maximálně využito systémových prostředků a~docíleno zrychlení provádění dotazů.

\subsection{MongoDB} \label{mongoDB}

\begin{figure}[!h]
  \centering
  \includegraphics[width=13cm]{template-fig/MetadataSchema.pdf}
  \caption{Schéma databáze pro metadata, obsahuje zatím pouze metadata pro pakety sdružované v~kolekci dokumentů typu PacketMetadata. Kolekce dokumentů typu \texttt{OtherForensicMetadata} je zde uvedena jako příklad pro rozšíření do budoucna.}
  \label{FIG_MetadataSchema}
\end{figure}

MongoDB slouží k~uchování registru metadat. Důvody k~zavedení podsystému metadat jsou uvedeny v~\ref{metadata}. Druh metadat pro nějaký typ forenzních dat lze reprezentovat jako dokument ve formátu JSON. Dokumenty stejného typu jsou pak ukládány do kolekce. Pro každý typ ukládaných forenzních dat existuje takový dokument. Při ukládání dat do Cassandry nebo HDFS je dokument metadat sestaven a~vyplněn klíčovými atributy, podle kterých bude možné později vyhledávat.

\vspace{0.5cm}
\noindent Pro pakety byl zvolen dokument typu \texttt{PacketMetadata} s~těmito atributy:

\begin{itemize}
    \item \texttt{id} -- Unikátní ID v~rámci MongoDB.
    
    \item \texttt{refId} -- Unikátní ID pro záznamy v~databázi Cassandra.
    
    \item \texttt{uri} -- Pokud jsou korespondující forenzní data uložena v~HDFS, je vyplněn tento atribut cestou k~datům v~HDFS.
    
    \item \texttt{databaseType} -- Určuje typ úložiště, povolenými hodnotami jsou \texttt{Cassandra} a~\texttt{HDFS}.
    
    \item \texttt{timestamp} -- Časové razítko paketu.
    
    \item \texttt{originalLength} -- Délka paketu v~bytech.
    
    \item \texttt{ethernetTypeValue} -- Hodnota z~ethernetové hlavičky paketu, která udává typ protokolu v~hexadecimálním formátu, např. 0x0800 pro IPv4, 0x86dd pro IPv6 atd.
    
    \item \texttt{ethernetTypeName} -- Hodnota z~ethernetové hlavičky paketu, která udává typ protokolu v~řetězcovém formátu, např. IPv4, IPv6, ARP atd.
    
    \item \texttt{srcLinkLayerAddress} -- Zdrojová fyzická adresa ve formátu \texttt{xx:xx:xx:xx:xx:xx}.
    
    \item \texttt{dstLinkLayerAddress} -- Cílová fyzická adresa ve formátu \texttt{xx:xx:xx:xx:xx:xx}.
    
    \item \texttt{ipProtocolValue} -- Hodnota z~IP hlavičky paketu, která udává typ transportního protokolu v~celočíselném formátu, např. 4 pro ICMPv4, 6 pro TCP, 17 pro UDP atd.
    
    \item \texttt{ipProtocolName} -- Hodnota z~IP hlavičky paketu, která udává typ transportního protokolu v~řetězcovém formátu, např ICMPv4, IGMP, TCP, IGP atd.
    
    \item \texttt{ipVersionValue} -- Hodnota z~IP hlavičky paketu udávající číslo verze IP protokolu, 4 pro IPv4, 5 pro ST, 6 pro IPv6 apod.
    
    \item \texttt{ipVersionName} -- Hodnota z~IP hlavičky paketu udávající verzi IP protokolu v~řetězcovém formátu, např. IPv4, ST, IPv6 atd.
    
    \item \texttt{srcIpAddress} -- Zdrojová IP adresa v~řetězcovém formátu, lze tedy uchovat IPv4 i~IPv6 adresu. IPv6 adresa může mít více řetězcových interpretací, např. řetězce \texttt{ff02:0:0:0:0:0:0:c} a~\texttt{ff02::c} vyjadřují tu samou IPv6 adresu. IP adresy jsou získány z~paketu pomocí knihovny Pcap4J \ref{pcap4j}, která IP adresy vrací jako Java objekty typu \texttt{InetAddress}. Tyto objekty nelze serializovat do databáze, proto jsou ukládány jen řetězcové hodnoty. Nicméně třída InetAddress nabízí statickou metodu \texttt{InetAddress 	getByName(String host)}, kterou lze IP adresy normalizovat na stejný řetězcový tvar. Obě následující volání vrátí stejný řetězec:
    
    \indent \texttt{InetAddress.getByName("ff02:0:0:0:0:0:0:c").getHostAddress()}
    
    \indent \texttt{InetAddress.getByName("ff02::c").getHostAddress()}
    
    \item \texttt{dstIpAddress} -- Cílová IP adresa ve stejném formátu jako zdrojová.
    
    \item \texttt{srcPort} -- Zdrojový port.
    
    \item \texttt{dstPort} -- Cílový port.
\end{itemize}

\noindent První čtyři atributy jsou společné pro všechny druhy metadat.

\subsubsection{Reaktivní dotazy}
Pro komunikaci s~databází MongoDB existuje několik ovladačů, tzn. synchronní, asynchronní, a~také ovladač založen na reaktivním paradigmatu. Poslední zmíněný byl využit pro distribuovaný repositář. Tento ovladač poskytuje asynchronní zpracování dotazů neblokujícím způsobem. Zcela implementuje aplikační rozhraní tzv. \texttt{Reactive Streams} \footnote{http://www.reactive-streams.org/}. Mezi silné stránky tohoto paradigmatu patří: funkcionální přístup, asynchronní zpracování chyb, jednoduchá multivláknovost \cite{oficReactiveX}. Často je prezentováno jako rozšíření návrhových vzorů Pozorovatel (angl. \texttt{Observer}) a~iterátor (angl. \texttt{Iterator}). Reaktivní paradigma se samozřejmě netýká jen databází, platí obecně a~lze s~ním vyvíjet celé aplikace.

% https://dzone.com/articles/what-are-reactive-streams-in-java
% http://vsadnajavu.cz/2017-06/odborne/spring-framework/spring-5-0-reactive/

Manipulaci s~metadaty zajišťuje tzv. reaktivní JPA (\texttt{Java Persistence API}) patřící pod projekt Spring. Tato vrstva využívá výše zmíněného reaktivního ovladače pro MongoDB. Následuje detailnější pohled na tento programovací model a~aplikační rozhraní \cite{springDataReactive}.

Základem je vytvoření entitní třídy, která reprezentuje objekty ukládané do tabulky databáze nebo v~tomto případě do kolekce. Pro entitní třídu lze definovat rozhraní, které představuje použití návrhového vzoru \texttt{Repository}. Výhodou je, že objekty nemají ponětí o~tom, jakým způsobem jsou ukládány. O~persistenci se postará Repository. Definované rozhraní představující Repository musí dědit rozhraní

\begin{lstlisting}[language=Java]
    interface ReactiveCrudRepository<T, ID>
\end{lstlisting}

\noindent se dvěma typovými parametry, kde typ \texttt{T} udává typ entitní třídy a~typ \texttt{ID} udává typ unikátního ID pro záznamy dané entitní třídy. Toto rozhraní definuje doménově specifické \texttt{CRUD} metody s~parametry reaktivních typů \texttt{Flux} a~\texttt{Mono}, které budou vysvětleny dále. Příkladem pro manipulaci s~metadaty je rozhraní:

\begin{lstlisting}[language=Java]
    interface PacketMetadataRepository extends
            ReactiveCrudRepository<PacketMetadata, String>
\end{lstlisting}

\noindent Projekt Spring Data se postará o~implementaci tohoto rozhraní pro všechny CRUD operace nabízené tímto rozhraním.

Reaktivní přístup byl zvolen hlavně z~důvodu vrstvy JPA, kterou zajišťuje sám Spring. Přístup pomocí asynchronních dotazů by šel využít taktéž, ale manipulace s~metadaty, ukládání a~dotazování, by byla těžkopádná, potřebovala výrazně více režijního kódu, a~byla by nepřehledná, protože asynchronní ovladač pracuje primárně na úrovně dokumentů vkládaných do kolekcí. S~tím by souviselo manuální sestavování a~parsování objektů reprezentujících dokument.

\subsubsection{Reaktivní typy}
Výchozími reaktivními typy jsou Flux a~Mono pocházející z~projektu \texttt{Project Reactor} (implementací reaktivních typů existuje více, další je např. \texttt{ReactiveX}). Flux slouží pro vztahy typu N, Mono pak pro vztahy typu 0 nebo 1 \cite{projectReactor}.
Reaktivní typy nejsou určeny k~tomu, aby zpracovaly požadavky nebo data rychleji, ve skutečnosti představují malou režii ve srovnání s~běžným blokujícím zpracováním. Jejich síla spočívá v~obsluze více požadavků paralelně, a~ve zpracování operací s~latencemi, např. dotaz pro data z~databáze nebo ze vzdáleného serveru, mnohem efektivněji. Poskytují lepší plánování zdrojů, zacházení s~časem a~latencemi. Na rozdíl od tradičního zpracování blokujícím způsobem, které pozastaví aktuální vlákno čekáním na výsledek operace, reaktivní aplikační rozhraní čekající na výsledek nestojí žádný čas, dotazuje se pouze na objem dat, který je schopné zpracovat. Zabývá se celými streamy dat, nikoliv pouze individuálními elementy jeden za druhým \cite{springReactiveTypes}.

Reaktivní aplikační rozhraní poskytuje operátory podobné streamům z~jazyka Java, ale tyto operátory pracují obecně s~jakoukoliv sekvencí, nejsou omezeny pouze na kolekce, a~umožňují definovat řetězec transformačních operací, které se aplikují na data procházející streamem. Streamy dokáží zpracovat synchronní i~asynchronní operace, data lze řetězit, sloučit, nebo na ně aplikovat různé transformace \cite{springReactiveTypes}.

Implementace reaktivního rozhraní je založena na výše zmíněné specifikaci Reactive Streams. Základním kamenem jsou čtyři rozhraní \texttt{Publisher}, \texttt{Subscriber}, \texttt{Subscription} a~\texttt{Processor}. Jejich zodpovědnosti jsou:
\begin{itemize}
    \item Publisher -- Poskytovatel potenciálně neomezeného počtu elementů v~sekvenci, odesílá je podle požadavků obdržených od svých příjemců. Může obsluhovat dynamicky v~čase mnoho příjemců.
    
    \item Subscriber -- Příjem elementů od poskytovatele, na elementy se dotáže sám. Typicky má tyto 3 metody: \texttt{onNext} -- zpracování elementu, \texttt{onError} -- zpracování chyby, a~\texttt{onComplete} -- signalizace dokončení operace \texttt{onNext}.
    
    \item Subscription -- Může být použito pouze jedním příjemcem. Představuje jednotku přijetí elementu od poskytovatele k~odběrateli.
    
    \item Processor -- Procesory jsou speciálním případem poskytovatele, který je zároveň příjemcem \cite{reactoreRefGuide}. Reprezentují jednotku vykonávání.
\end{itemize}

\noindent Reaktivní typy Flux a~Mono implementují rozhraní poskytovatele. Současně umožňují přidávat transformační operace ke každému elementu sekvence. Jednoduché je i~zpracování chyb asynchronním způsobem bez použití bloků \texttt{try} a~\texttt{catch}. Klientský kód se chová jako odběratel.

\section{Architektura systému} \label{architecture}
Tato sekce se zabývá architekturou systému. Následující dva diagramy tříd \ref{FIG_CommunicationClassDiagram} a~\ref{FIG_DRCoreClassDiagram} zobrazují klíčové třídy, metody a~závislosti. Z~důvodu přehlednosti obsahují pouze důležitá rozhraní a~třídy systému. Nejsou zde vyznačeny všechny implementační třídy a~všechny vazby závislosti (vynechány jsou především závislosti na třídy pocházející z~knihoven).

Diagram \ref{FIG_CommunicationClassDiagram} představuje komunikační jádro systému z~pohledu distribuovaného repositáře. Repositář obsahuje třídu \texttt{DistributedRepositoryConsumer} obsluhující komunikaci s~Kafkou. Má také referenci na správce všech obslužných akcí pro příkazy -- \texttt{handlerManager}. Všechny typy příkazů jsou určeny výčtovým typem \texttt{Command}. Metoda \texttt{listen} (je označena anotací \texttt{@KafkaListener} -- více v~\ref{springKafka}), je zavolána při přečtení zprávy požadavku, která je reprezentována třídou \texttt{KafkaRequest}, z~fronty. Konzument přijme zprávu z~fronty, zjistí typ příkazu a~vybere podle něj korespondující obsluhu ze správce handler-ů. Handler potom zpracuje příkaz. V~rámci zpracování může být odeslána asynchronní odpověď klientovi, pokud klient nastavil při odeslání zprávy parametry \texttt{awaitsResponse} a~\texttt{responseTopic}. K~odesílání odpovědí do Kafka fronty slouží třída \texttt{ResponseProducer}. Odpověď bude obsahovat základní informace jako například kód a~status, a~také ID, aby si klient dokázal spárovat zpracované zprávy. Více informací ohledně sktruktury odpovědí je uvedeno v~\ref{designCommunication}.

Všechny použité technologie, tzn. Kafka, Cassandra, MongoDB, i~HDFS, jsou distribuované, je možné přidávat další výpočetní uzly pro navýšení výkonu, a~všechny tak počítají s~rozšiřitelností do budoucna.

Konfiguraci parametrů systému a~technologií lze provést pomocí specifických souborů s~příponou \texttt{.properties} obsahujících páry klíč-hodnota (konfigurace uvedena v~příloze \ref{configuration}).

\begin{figure}[!h]
  \centering
  \includegraphics[width=15cm]{template-fig/CommunicationClassDiagram.pdf}
  \caption{Diagram tříd komunikace systému.}
  \label{FIG_CommunicationClassDiagram}
\end{figure}

\begin{figure}[!h]
  \centering
  \includegraphics[width=15cm]{template-fig/DRCoreClassDiagram.pdf}
  \caption{Diagram tříd jádra systému.}
  \label{FIG_DRCoreClassDiagram}
\end{figure}

\subsection{Rozhraní pro dotazování dat} \label{queryDataInterface}
V~této sekci bude uvedeno jakým způsobem lze zadávat kritéria pro dotazování. Kritéria slouží k~filtrování záznamů, uplatní se na záznamy -- dokumenty metadat. Formát jednotlivých kritérií výrazně odpovídá tvaru parametrů dokumentů v~MongoDB.

Jeden objekt kritéria je reprezentován instancí třídy \texttt{KafkaCriteria} pocházející z~modulu Communication. Obsahuje tyto parametry:

\begin{itemize}
    \item \texttt{field} -- Řetězcová hodnota udávající název atributu v~dokumentu MongoDB.
    
    \item \texttt{operation} -- Jedná se o~hodnotu výčtu \texttt{MetadataOperation}, který obsahuje tyto názvy operací -- \texttt{is}, \texttt{ne}, \texttt{lt}, \texttt{lte}, \texttt{gt}, \texttt{gte}, \texttt{in}, \texttt{nin}. Tyto názvy porovnávacích operací reflektují názvy metod ve třídě \texttt{Criteria} z~modulu Spring Data, takže lze pomocí reflexe tento objekt sestavit. Způsob sestavení přes reflexi je zvolen kvůli chybějící závislosti modulu Persistence klientské aplikaci.
    Objekt \texttt{Criteria} lze potom předat do reaktivního dotazu do MongoDB.
    
    \item \texttt{value} -- Představuje hodnotu, podle které se atribut \texttt{field} bude filtrovat. Lze zadat libovolný Java objekt.
    
    \item \texttt{values} -- Operace \texttt{in} a~\texttt{nin} vyžadují seznam hodnot k~filtrování. K~předání seznamu objektů slouží tento parametr.
\end{itemize}

\noindent Objektů typu \texttt{KafkaCriteria} lze sestavit libovolné množství, a~předat je poté do zprávy požadavku \texttt{KafkaRequest} \ref{designCommunication}. Jednotlivé filtrovací operace se společně s~uvedenými atributy a~hodnotami zřetězí pomocí logické operace \texttt{AND} do objektu třídy \texttt{Criteria}.

\subsection{Scénáře}
Tato sekce uvede podporované příkazy a~jakým způsobem jsou zpracovány. Podporovány jsou dva scénáře -- uložení PCAP souboru a~čtení paketů podle zadaných kritérií. Jádro distribuovaného repositáře ilustruje diagram tříd \ref{FIG_DRCoreClassDiagram}.

Zpracování proběhne následovně -- metoda \texttt{listen} třídy DistributedRepositoryConsumer zkonzumuje zprávu z~fronty a~zavolá metodu \texttt{consume}, která spustí obsluhu příkazu. Aktuálně jsou definovány dvě obsluhy:

\begin{itemize}
    \item Příkaz \texttt{STORE\_PCAP} - Zpracování řeší třída \texttt{StorePcapHandler}.
    \item Příkaz \texttt{LOAD\_PCAP} - Obsluhu poskytuje třída \texttt{LoadPcapHandler}. 
\end{itemize}

\subsubsection{Zpracování a~uložení PCAP souboru}
Klient odešle příkaz \texttt{STORE\_PCAP} s~dodatečnými parametry udávajícími zdroj dat a~výstupní frontu (více v~\ref{designCommunication}). Po přijetí zprávy požadavku proběhne uložení PCAP souboru do pomocného souboru na lokálním disku (z~HDFS a~nebo z~paměti RAM), protože knihovna Pcap4J neumí zpracovávat PCAP soubory z~HDFS ani z~paměti RAM. Následně proběhne parsování na jednotlivé pakety. K~tomu slouží rozhraní \texttt{PcapParser<T>} s~implementací dodanou ve třídě \texttt{PcapParserImpl}. Pakety jsou jeden po druhém ukládány do databáze Cassandra asynchronním způsobem \ref{cassandra}. Současně jsou také vytvářeny záznamy metadat. Extrahování informací z~paketů zajišťuje jednotné rozhraní \texttt{PacketExtractor<T, B>} s~několika implementacemi podle vrstev TCP/IP modelu -- \texttt{EthernetPacketExtractor}, \texttt{IpPacketExtractor} a~\texttt{TransportPacketExtractor}. Záznamy metadat se ukládají reaktivním způsobem \ref{mongoDB} po kolekcích obsahujících několik záznamů (počet záznamů, které se uloží najednou, lze konfigurovat pomocí položky \texttt{packet.metadata.max.list.size} \ref{configuration}). Až jsou všechny pakety i~záznamy metadat uloženy, lze odstranit dočasný PCAP soubor z~lokálního disku. Poté je případně odeslána odpověď klientovi s~návratovým kódem \texttt{OK(200)}.

\subsubsection{Čtení paketů podle kritérií}
Klient odešle příkaz \texttt{LOAD\_PCAP} s~dodatečnými parametry podobně jako v~předchozím případě. Navíc zadá dotazovací kritéria jejichž sémantika je uvedena v~\ref{queryDataInterface}. Po přijetí zprávy požadavku proběhne sestavení objektu \texttt{Criteria} z~kritérií uvedených ve zprávě požadavku. Tento objekt je předán do \texttt{packetMetadataRepository}, kde je pomocí Spring Data API provedeno čtení metadat paketů z~MongoDB. Čtení probíhá reaktivně se zabudovanými \texttt{callback}-y, které pro každý načtený záznam spustí další čtení, v~tomto případě už hodnoty celého paketu z~databáze Cassandra. Načítání paketů probíhá zase asynchronně, k~metodě je přidán další \texttt{callback}, který obslouží načtený paket tím, že jej zapíše do PCAP souboru (klient musí zadat cestu k~výslednému PCAP souboru pomocí atributu \texttt{dataSource} ve zprávě požadavku \ref{designCommunication}, předání souboru přes Kafku není možné z~důvodu neznámé velikosti a~počtu nalezených paketů). Přístup k~výslednému PCAP souboru je možný skrze rozhraní \texttt{PcapDumper<T>} implementovaného ve třídě \texttt{DumperImpl}. PCAP soubor je až do konce čtení paketů uložen jako dočasný soubor (kvůli limitaci Pcap4J knihovny), potom je přesunut na HDFS. Celý proces končí odesláním odpovědi klientovi.

\subsection{Rozšíření pro nový typ forenzních dat}
Rozšíření v~podobě podpory nových druhů digitálních forenzních dat je velmi jednoduché. Spočívá v~přídání implementace:

\begin{itemize}
    \item Rozšíření výčtů \texttt{Command}, \texttt{Operation} a~\texttt{DataType}, kde lze přidat nové typy příkazů.
    
    \item Definovat odpovídající tabulky v~databázi, přidat implementaci pro práci s~databází.
    
    \item K~uložení metadat je nutné definovat novou entitní třídu včetně rozhraní \texttt{Repository}.
    
    \item Zpracování příkazu -- Je potřeba specializovat třídu \texttt{BaseHandler} novou implementací, která bude kompletně řídit zpracování příkazu (\texttt{BaseHandler} má přístup k~HDFS a~k~šabloně obsluhující komunikaci s~Kafkou). Tato implementace se musí nakonfigurovat jako bean ve třídě \texttt{HandlerBeans} a~asociovat s~typem příkazu přes správce handlerů v~\texttt{HandlerManagerBeans}.
\end{itemize}

\noindent Po těchto krocích lze z~klientské aplikace zasílat zprávy požadavků s~novým typem příkazu.

\section{Klientská aplikace}
Pro účely testování byla implementována klientská demo aplikace ProducerDemo \ref{FIG_Architecture}. Jedná se o~aplikaci postavené na Spring Boot s~možností auto-konfigurace. Podporuje zaslání zpráv pro dva výše zmíněné scénáře -- požadavek pro uložení PCAP souboru, a~požadavek pro čtení paketů podle kritérií. Data předává v~obou případech přes HDFS z~důvodu šetření paměti RAM. Odpovědi z~distribuovaného úložiště přijímají dvě rozdílné komponenty:

\begin{itemize}
    \item \texttt{AcknowledgementConsumerHandler} -- Přijímá zprávy pouze z~fronty \texttt{output\_topic}.
    
    \item \texttt{ErrorConsumerHandler} -- Přijímá zprávy z~chybové fronty \texttt{error\_topic}.
\end{itemize}

\noindent Čtení zpráv z~těchto dvou front je rozděleno do různých tříd pro potenciálně lepší zpracování chyb. Aktuálně jsou všechny příchozí odpovědi (v~obou třídách) zapsány do logů.

Příklady spuštění aplikací jsou uvedeny v~příloze \ref{launching}.

\section{Logování}
Logování (angl. \texttt{logging}) pomáhá trasování běžícího systému. Existuje mnoho implementací pro trasování v~Java (\texttt{Log4j}, \texttt{Log4j 2}, \texttt{Logback} atd.). Konkrétní implementaci už v~sobě jako závislost zahrnuje přímo Spring Boot. Logování lze konfigurovat mnoha parametry. Lze určit, do kterého souboru se bude zapisovat, jakou úroveň logování použít, formát zapisovaných zpráv, nastavení se může lišit pro jednotlivé balíčky apod. Každá implementace logovacího systému by měla podporovat následující úrovně logování -- \texttt{TRACE}, \texttt{DEBUG}, \texttt{INFO}, \texttt{WARN}, \texttt{ERROR}, \texttt{OFF}. Jednotlivé úrovně potom vyjadřují význam zprávy v~logu. Odpovídající nastavení v~systému distribuovaného úložiště lze vidět v~příloze \ref{configuration}.

\section{Zpracování chyb}
Při běhu systému může nastat několik druhů chyb -- nefungující připojení k~databázi, pokud databáze neběží korektně; nedostupnost Kafka front; chyby při ukládání souborů na HDFS např. kvůli kolizi jmen nebo nedostatečnému oprávnění; chyby při parsování PCAP souboru či zápisu do PCAP souboru. Výjimky jsou odchyceny v~blocích \texttt{try} a~\texttt{catch}, v~případě reaktivních či asynchronních dotazů jsou zaregistrovány odpovídající \texttt{callback}-y pro chybové stavy. Po odchycení výjimek jsou výjimky logovány s~úrovní \texttt{ERROR}. Poté je sestavena odpověď pro klienta s~návratovým kódem \texttt{INTERNAL\_SERVER\_ERROR(500)} a~odpověď odeslána do chybové fronty zadané parametrem \texttt{errorTopic} uvedeného ve zprávě požadavku.

\chapter{Výkon} \label{chapter_performance}
Tato kapitola uvádí zhodnocení výkonosti systému, počáteční a~finální implementace. Zaměřuje se také na optimální hardwarové konfigurace, které jsou doporučeny pro provoz použitých distribuovaných technologií.

\section{Prototyp} \label{prototypeSection}
V~rámci semestrálního projektu byl implementován jednoduchý prototyp distribuovaného repositáře reflektující body uvedené v~kapitole návrhu distribuovaného úložiště \ref{distrRepDesignChapter}. Prototyp sloužil pouze pro ověření základních aspektů návrhu jako např. komunikace s~klientem, práce s~databází Cassandra a~parsování PCAP souborů na pakety. Podporoval pouze jeden příkaz -- \texttt{STORE\_PCAP}, a~to také bez použití metadat. Prototyp nebyl vhodný pro nasazení neboť obsahoval několik nedostatků, které byly v~průběhu další implementace eliminovány. Mezi nejdůležitější nedostatky patřily tyto záležitosti:

\begin{itemize}
    \item předávání všech dat libovolné velikosti v~binární podobě přes systém Kafka,
    
    \item manuální a~neprůhledná konfigurace technologií,
    
    \item neefektivní komunikace s~databází,
    
    \item nebylo optimálně využito hardwarových prostředků,
    
    \item celé objekty paketů byly do databáze serializovány.
\end{itemize}

\subsection{Eliminace nedostatků prototypu} \label{improvementsInImpl}
Původně bylo navrženo a~i~v~prototypu implementováno předávání dat pouze přes systém Kafka. Při velkých objemech přenášených dat bylo plýtváno pamětí RAM a~současně také diskovým prostorem, protože Kafka ukládá přijaté zprávy i~na disk. Tento problém vyřešilo předávání dat přes HDFS. Tímto způsobem jsou data uložena jen jednou a~to na disku, zároveň je šetřena paměť RAM.

Po přidání HDFS a~databáze MongoDB pro metadata značně narostl počet konfigurovatelných parametrů. Manuálním načítáním konfiguračních parametrů a~vytvářením mnoha objektů realizujících připojení do databází nebo na disk se také ztížila orientace v~kódu, který se stal nepřehledným. Tyto operace velmi usnadnila integrace stávajícího kódu s~projekty Spring, a~hlavně získání auto-konfigurace ze Spring Boot \ref{springProjects}. Porovnáním diagramu tříd prototypu \ref{FIG_PrototypeClassDiagram} a~výsledného systému \ref{FIG_CommunicationClassDiagram} lze vidět i~zjednodušení v~použití tříd Kafky.

\noindent Ukládání paketů do databáze Cassandra probíhalo i~v~prototypu asynchronně, ale nebylo žádným způsobem řešeno vykonávání několika dotazů současně. Díky tomu nastávalo často čekání vlákna apod. Přístupy pro řízení dotazů a~pro maximální využití dostupných prostředků jsou uvedeny v~sekci \ref{cassandra}.

V~původní implementaci byly pakety také ukládány neefektivně z~pohledu výkonu a~velikosti dat. Každý objekt reprezentující paket byl serializován na pole bytů a~toto pole pak uloženo do databáze. Konverze na pole bytů vyžadovala značnou režii, a~hlavně velikost serializovaného objektu reprezentujícího paket byla značně vyšší než skutečná velikost paketu. Ve finální implementaci je pole bytů, které obsahuje hodnotu paketu, získáno přímo z~objektu paketu pomocí metody \texttt{byte[] getRawData()} knihovny Pcap4J.

\subsection{Porovnání výkonu prototypu a~finálního systému}
Test rychlosti byl proveden na této hardwarové konfiguraci:

\vspace{0.5cm}
\noindent \texttt{CPU: Intel Core i5-4200U 1.6 GHz @ 2.6 GHz} \\
\texttt{RAM: 8 GB} \\
\texttt{OS: Windows 8.1}

\vspace{0.5cm}
\noindent Big data technologie Kafka, ZooKeeper, HDFS, Cassandra a~MongoDB běžely jako oddělené kontejnery v~prostředí Docker, více informací o~běhovém prostředí je uvedeno v~příloze \ref{dockerEnv}. Virtuální stroj v~rámci Docker měl toto nastavení:

\vspace{0.5cm}
\noindent \texttt{CPU: 2 cores} \\
\texttt{RAM: 4 GB} \\
\texttt{OS: boot2docker}

\subsubsection{Prototyp}

\begin{figure}[!h]
    \centering
    \includegraphics[width=15cm]{template-fig/PrototypePerformanceChart.pdf}
    \caption{Graf zobrazující počet uložených paketů z~jednoho PCAP souboru za čas.}
    \label{FIG_PerformanceChartPrototype}
\end{figure}

\noindent Pro toto srovnávací testování byly použity pouze PCAP soubory obsahující od stovkek paketů po několik tisíc. Větší PCAP soubory už prototyp na uvedené HW konfiguraci nedokázal zpracovávat z~důvodu vyčerpání paměti RAM.

Tabulka \ref{tablePerformancePrototype} obsahuje informace z~měření rychlosti prototypu. První sloupec udává velikost PCAP souboru v~bytech, druhý sloupec obsahuje počet paketů na daný PCAP soubor a~třetí sloupec zobrazuje průměrnou velikost paketu v~bytech. Čas uvedený ve čtvrtém sloupci je měřen od odeslání příkazu od klienta po obdržení odpovědi z~repositáře. Poslední pátý sloupec udává počet paketů zpracovaných za sekundu. Pro test PCAP souborů větších než 30 MB (obsahujících přes 100 tisíc paketů) už výše uvedená konfigurace nestačila. Po několika minutách aplikace zhavarovala pro nedostatek paměti RAM.

\subsubsection{Finální systém}

\begin{figure}[!h]
    \centering
    \includegraphics[width=15cm]{template-fig/PerformanceChartFinal.pdf}
    \caption{Graf zobrazující počet uložených paketů z~jednoho PCAP souboru za čas.}
    \label{FIG_PerformanceChartFinalSystem}
\end{figure}

\noindent Tabulka \ref{tablePerformanceFinalSystem} udává naměřená data pro výsledný systém. Z~tabulky, i~porovnáním grafů \ref{FIG_PerformanceChartPrototype} a~\ref{FIG_PerformanceChartFinalSystem}, lze vidět podstatné zvýšení výkonu. Pro takto malé PCAP soubory je už ve finálním systému většina času spotřebována komunikací klienta se systémem přes Kafku než parsováním paketů, získáváním metadat, a~ukládáním metadat a~hodnot paketů do databází. I~přes přidaný podsystém metadat a~předávání PCAP souborů přes HDFS bylo pomocí úprav uvedených v~\ref{improvementsInImpl} docíleno zrychlení systému.

Z~uvedeného grafu pro rychlost prototypu \ref{FIG_PerformanceChartPrototype} vyplývá lineární složitost. Podle údajů v~tabulce \ref{tablePerformancePrototype} lze průměrně zpracovat 89 paketů za sekundu při průměrné velikosti jednoho paketu 450 bytů. V~grafu výsledného systému \ref{FIG_PerformanceChartFinalSystem} už se jedná o~velmi malá čísla a~tak lineární složitost není z~grafu přímo patrná. Přesto pro úplnost, lze zpracovat přibližně 2242 paketů za sekundu, při průměrné velikosti jednoho paketu 450 bytů.

\vspace{0.5cm}
\noindent Pozn.: Z~výše uvedené hardwarové konfigurace vyplývá, že nebylo využito maximálního potenciálu použitých technologií, a~to zejména distribuovanosti systému, který by běžel místo jednoho počítače v~clusteru. V~takovém prostředí a~s~rychlým internetovým připojením by byla výkonnost systému znatelně vyšší.

\subsubsection{Výsledek srovnání}

\begin{figure}[!h]
    \centering
    \includegraphics[width=15cm]{template-fig/PerformanceChartComparePrototypeAndFinal.pdf}
    \caption{Graf porovnávající rychlost prototypu a~finálního systému.}
    \label{FIG_PerformanceChartComparePrototypeAndFinal}
\end{figure}

\noindent Graf \ref{FIG_PerformanceChartComparePrototypeAndFinal} je sloučením grafů \ref{FIG_PerformanceChartPrototype} a~\ref{FIG_PerformanceChartFinalSystem} a~zobrazuje porovnání rychlosti prototypu a~výsledného systému na zvolené množině vstupních dat. Z~grafu lze zpozorovat nárůst výkonu na stejné hardwarové konfiguraci pro stejná vstupní data. Pro tato data došlo ke 14 až 38násobnému zrychlení.

\section{Výkonnostní test finálního systému}
Předchozí porovnání prototypu a~výsledného systému bylo provedeno na běžně dostupné hardwarové konfiguraci, která bývá součástí levnějších notebooků. Tomu odpovídala i~zvolená množina vstupních dat obsahující pouze několik tisíc paketů. V~této sekci bude proveden test výkonnosti na silnější HW konfiguraci se vstupními PCAP soubory, které dohromady obsahují miliony paketů.

\subsubsection{Ukládání paketů}
Testovací scénář zahrnuje odeslání příkazů \texttt{STORE\_PCAP} z~klientské aplikace. Klient nečeká na odpovědi z~distribuovaného úložiště, prostě odesílá zprávy s~příkazy, dokud existují PCAP soubory ve zvoleném adresáři (název adresáře obsahující PCAP soubory je předán jako vstupní parametr přes příkazovou řádku). Příkazy jsou uchovány v~Kafka frontě a~postupně čteny v~distribuovaném repositáři. Po zpracování jednotlivých příkazů se odesílají odpovědi klientské aplikaci.

Testovací sada zahrnovala 102 PCAP souborů o~velikosti 67 až 270 MB, z~nichž každý obsahoval 500 000 paketů s~výjimkou posledního souboru, ten pouze 351 631 paketů. Dohromady se tedy jednalo o~10.3 GB dat a~50 851 631 paketů.

\subsubsection{Čtení paketů}
Prohledávání bylo spuštěno nad 50 851 631 pakety uloženými v~předchozím scénáři. Za zmínku ještě stojí, že systém nebyl v~průběhu testu zastaven. Pro otestování rychlosti systému z~hlediska čtení paketů podle kritérií byla odeslána zpráva obsahující příkaz \texttt{LOAD\_PCAP} s~následujícími kritérii:

\vspace{0.5cm}
\texttt{field = ipProtocolName} \\
\indent \texttt{operation = EQ} \\
\indent \texttt{value = TCP}

\vspace{0.5cm}
\texttt{field = dstPort} \\
\indent \texttt{operation = IN} \\
\indent \texttt{value = [443, 80]}

\vspace{0.5cm}
\noindent Z~těchto kritérií byl sestaven následující výraz, který byl odeslán v~databázovém dotazu:

\vspace{0.5cm}
\verb|{ "ipProtocolName" : "TCP", "dstPort" : { "$in" : [443, 80] } }|

\subsection{HW konfigurace}
Testovacím strojem je notebook \texttt{Fujitsu Celsius H730}, specifikace:

\vspace{0.5cm}
\noindent \texttt{CPU: Intel Core i7-4910MQ 2.9 GHz @ 3.9 GHz} \\
\texttt{RAM: 32 GB} \\
\texttt{Drive: SSD Samsung 500 GB} \\
\texttt{OS: Windows 7 Enterprise}

\vspace{0.5cm}
\noindent Virtuální stroj v~rámci Docker měl toto nastavení:

\vspace{0.5cm}
\noindent \texttt{CPU: 4 cores} \\
\texttt{RAM: 24 GB} \\
\texttt{OS: boot2docker}

\subsubsection{Ukládání paketů}

\begin{figure}[!h]
    \centering
    \includegraphics[width=15cm]{template-fig/PerformanceChartFinalBigData.pdf}
    \caption{Graf zobrazující počet uložených paketů z~jednoho PCAP souboru za čas.}
    \label{FIG_PerformanceChartFinalBigData}
\end{figure}

\noindent Tabulka \ref{tablePerformanceFinalSystemBigData} udává souhrn statistických informací z~měření. První sloupec uvádí celkovou velikost všech vstupních PCAP souborů v~bytech, druhý sloupec počet paketů, které byly ukládány. Třetí sloupec zobrazuje průměrnou velikost paketu v~bytech. Čas uvedený ve čtvrtém sloupci je měřen od odeslání prvního PCAP souboru z~klientské aplikace do obdržení odpovědi z~distribuovaného úložiště posledního zpracovaného PCAP souboru. Průměrně bylo zpracováno a~uloženo 20 850 paketů za sekundu.

\begin{table}[h!]
    \centering
    \begin{tabular}{| l | l | l | l | l |}
    \hline
    \texttt{PCAP size (B)}   &   \texttt{Count of packets}   &   \texttt{Avg. packet size} &  \texttt{Time (s)} &   \texttt{Packets/s} \\ \hline
    11 156 484 529 & 50 851 631 & 220 & 2516 & 20 850 \\ \hline
    \end{tabular}\par
    \bigskip
    \caption{Tabulka obsahuje data naměřená při testování výkonnosti finálního systému pro příkaz \texttt{STORE\_PCAP}.}
    \label{tablePerformanceFinalSystemBigData}
\end{table}

\subsubsection{Čtení paketů}
Čas realizace operace od odeslání zprávy od klienta po obdržení odpovědi byl 122 sekund. Celkem bylo načteno 473 243 paketů průměrnou rychlostí 3880 paketů za sekundu. Tyto pakety byly uloženy do jednoho výsledného PCAP souboru na HDFS.

\section{Doporučené HW požadavky distribuovaných technologií}
I~když se jedná o~distribuované technologie schopné běžet na mnoha uzlech, každý uzel by měl splňovat základní hardwarové požadavky podle dané nasazené technologie.

\subsection{Kafka}
Zdrojem je převážně dokument věnující se klíčovým záležitostem před nasazením Kafky \cite{kafkaDeployment}. Kafka velmi spoléhá na souborový systém pro ukládání zpráv. Všechna data jsou okamžitě zapisována do perzistentního logu v~souborovém systému, do \texttt{pagecache} kernelu. Kafka moc nevyužívá \texttt{heap space}, nevyžaduje pro něj přiřazení víc než 5 GB.
Je ale potřeba mít dostatečnou velikost paměti RAM k~načtení aktivních příjemců a~odesílatelů. Vhodnou volbou je 32-64 GB paměti.

Většina konfigurací, kde je Kafka nasazena, nevyžaduje značný výkon procesoru. Výjimkou je však případ, kdy je zapnuto \texttt{SSL}, požadavky na výkon CPU potom mohou vzrůst. Je doporučeno zvolit moderní procesor s~více jádry, běžný Kafka cluster využije 24 jader. Větší počet jader má větší význam než vyšší frekvence procesoru.

Je také doporučeno nainstalovat více disků pro získání optimální propustnosti a~nesdílet tyto disky s~jinými aplikacemi nebo aktivitami operačního systému, aby byla zaručena nízká latence \cite{kafkaBestPractises}. Jisté výhody mají i~SSD disky, případně zapojení disků v~\texttt{RAID}. Důležitou součástí distribuovaného systému je rychlá a~spolehlivá síť s~nízkými latencemi při přenosech. Moderní ethernetová připojení s~rychlostí 1 Gb/s, či 10 Gb/s jsou dostatečná. Nedoporučuje se provozovat clustery, jejichž uzly se nachází v~geograficky vzdálených lokacích.

\subsection{Cassandra}
Výběr hardware závisí na konkrétním případu použití. Správná kombinace paměti RAM, CPU, disků, počtu uzlů a~sítě je obrovsky rozdílná pro prostředí se statickými daty, ke kterým se přistupuje zřídka, a~pro prostředí s~nestálými daty, ke kterým se přistupuje často \cite{cassandraPlanningHW}. Pro otestování clusteru před nasazením lze využít nástroje \texttt{cassandra-stress}, který provede řadu výkonostních testů, více na webových stránkách společnosti DataStax \footnote{https://docs.datastax.com/en/dse/6.0/dse-admin/datastax\_enterprise/tools/toolsCStress.html}.

Cassandra běží ve virtuálním stroji Java s~přidělenou fixní velikostí \texttt{heap}-u. Cassandra používá značný objem paměti RAM mimo \texttt{heap} pro kompresi metadat, \texttt{bloom} filtry, řádky, klíče, čítače atd. Využívá výhod \texttt{pagecache} operačního systému, kam ukládá části naposledy manipulovaných souborů z~RAM pro okamžité znovupoužití. 
Minimální produkční server vyžaduje aspoň 2 jádra procesoru a~aspoň 8 GB RAM \cite{cassandraHW}. Typická konfigurace bývá 8 a~více jader spolu s~32 GB RAM.

Cassandra je vysoce vícevláknová, obsluhující mnoho souběžných požadavků (čtení i~zápisů) v~mnoha vláknech běžících na tolika jádrech CPU, kolik je dostupných. Zápis probíhá do tzv. \texttt{commitlog}-u a~poté vkládáním dat do \texttt{memtable} (optimalizovaná cache pro data, která mohou být vyhledána pomocí klíče), takže operace zápisu bývají především limitované procesorem. V~důsledku toho se po přidání dalších výpočetních jader zvýší propustnost čtení i~zápisů \cite{cassandraHW}.

Jako diskové jednotky jsou doporučeny SSD pro všechny připojené uzly. Poskytují extrémně nízkou latenci pro náhodná čtení, zároveň i~dostatečný výkon pro sekvenční operace zápisů. Pokud Cassandra běží na více uzlech, minimální požadovaná rychlost sítě je 1 Gb/s.

\subsection{MongoDB}
I~když je MongoDB velmi flexibilní a~jednoduchá databáze z~hlediska vývoje aplikací, liší se od běžných relačních databází ve správě zdrojů, takže je potřeba pečlivě zvážit výběr hardware pro nasazení.

Existují dva základní koncepty týkající se architektury MongoDB \cite{hwProvisioningMongoDB}:

\begin{itemize}
    \item Technika \texttt{sharding} - MongoDB spravuje oddíly dat napříč servery použitím techniky \texttt{sharding}. Vyvažování dat napříč úseky (angl. \texttt{shards}) je automatické, úseky lze přidávat nebo odpojovat bez přerušení běhu databáze.
    
    \item Replikace - MongoDB spravuje mnoho redundantních kopií dat pro okamžitou dostupnost.
\end{itemize}

\noindent Pro aplikace zaměřující se na masivní čtení dat, je doporučeno dimenzovat servery tak, aby udržely celou množinu dat v~paměti, kvůli okamžité dostupnosti \cite{hwProvisioningMongoDB}.

Ukládací nástroj \texttt{WiredTiger}, který MongoDB používá, poskytuje vylepšenou propustnost a~kompresi. Má cache, která zahrnuje soubor pro každou kolekci a~index. Hrubě řečeno, 50\% paměti RAM serveru bude určeno této cache. Pracovní množina je soubor indexů a~dokumentů, ke kterým je často přistupováno. Pokud lze uchovat pracovní množinu v~paměti RAM, bude docházet k~menšímu počtu I/O operací. Vhodné je, aby byla velikost paměti RAM větší než pracovní množina, ale menší než skutečná velikost dat \cite{sizeYourMongoDBClusters}.

\texttt{WiredTiger} je vícevláknový, dokáže těžit z~dodatečných procesorových jader. Konkrétně, celkový počet aktivních vláken vztahujících se k~počtu dostupných procesorů dokáže ovlivnit výkon. Propustnost se zvyšuje společně s~rostoucím počtem souběžných aktivních operací až do počtu procesorů. Propustnost se snižuje, jestli počet souběžných aktivních operací převýší počet procesorových jader. Očividné zrychlení poskytnou také SSD jednotky výměnou za standardní plotnové pevné disky \cite{mongoDBProductionNotes}.

\subsection{HDFS}
U~HDFS a~Hadoop obecně záleží na konkrétním použití. Jiná konfigurace bude vyžadována pro MapReduce úlohy, jiná pro integraci s~technologiemi Apache Spark, Apache HBase apod. Cílem používání platformy Hadoop je provoz na cenově dostupném hardware místo vysokorychlostních strojů \cite{hadoopHardware}.

MapReduce ani další technologie nejsou v~distribuovaném úložišti použity. HDFS slouží pouze jako úložiště dat, důležitým požadavkem je zajistit dostatek diskového prostoru. Hadoop je náročný na ukládací prostor a~je efektivní v~prohledávání, nevyžaduje však drahé a~velmi rychlé disky \cite{bestPracticesHadoopHW}.

Pokud dojde k~nasazení Hadoop na více uzlů, je zapotřebí poskytnout dostatečně rychlé síťové připojení, aby uzly mohly rychle a~efektivně komunikovat.

\chapter{Závěr}
Kapitola uvede zhodnocení dosažených výsledků. Následně budou představena navržená rozšíření z~pohledu dalšího vývoje systému, po jejichž implementaci by systém nabídl nové možnosti a~lepší použitelnost.

\section{Výsledky}
Teoretická část práce se zabývá úvodem do forenzní analýzy digitálních dat. Dále jsou prozkoumány existující systémy pro uložení digitálních forenzních dat (včetně systému AFF4). Jako úložiště pro digitální forenzní data a~obecně Big data jsou představeny distribuované databáze včetně jejich vlastností, dále NoSQL databáze a~distribuovaný souborový systém HDFS z~platformy Hadoop.

V~další části diplomové práce bylo navrženo distribuované úložiště rozsáhlých digitálních forenzních dat včetně aplikačního rozhraní. Byly vybrány vhodné komponenty a~technologie pro realizaci -- Kafka, HDFS, a~NoSQL databáze Cassandra a~MongoDB. Komunikace klienta s~úložištěm probíhá pomocí asynchronního zasílání zpráv, které obsahují ovládací příkazy.

Distribuované úložiště mělo splňovat několik základních požadavků. Prvním z~nich bylo umožnit optimální přístup k~datům. Sekvenční přístup je zajištěn systémem HDFS, náhodné čtení a~dotazování je pak zajištěno podsystémem metadat.
Architektura úložiště také počítá s~přidáváním podpory pro nové druhy forenzních dat. Přidání podpory za běhu je implicitně realizováno přijímáním zpráv přes Kafku.

Implementovaný systém je založen na distribuovaných Big data technologiích počítajících se škálovatelností. S~podporou Spring Boot a~ostatních Spring projektů lze jednoduše konfigurovat celý systém. Detaily k~běhovému prostředí implementovaných aplikací jsou uvedeny v~příloze \ref{dockerEnv}.

V~průběhu implementace úložiště bylo provedeno několik úprav ke zvýšení propustnosti a~výkonu systému. Největší dopad na výkon potom mělo asynchronní ukládání a~čtení dat z~databáze, čímž se efektivně využívají hardwarové prostředky. Po aplikaci úprav byly zjištěny rozdíly v~rychlosti původního a~výsledného implementovaného systému.

Po realizaci distribuovaného repositáře bylo provedeno měření výkonnosti pro desítky milionů paketů vstupních dat. Rychlost ukládání a~čtení závisí na hardwarové konfiguraci stroje, na kterém je systém distribuovaného úložiště nasazen. Na závěr byly také uvedeny hardwarové požadavky zvolených Big data technologií.

\section{Návrh rozšíření}
Zde budou diskutována případná rozšíření, která by poskytla pokročilé vlastnosti nástroje, a~ještě větší použitelnost.

\subsubsection{Kritéria pro dotazování}
Aktuální stav dotazování podle kritérií zahrnuje tvorbu výrazu, jehož podvýrazy jsou propojeny pouze operátorem \texttt{AND}. Podvýraz je tvořen porovnávacím operátorem (\texttt{is}, \texttt{ne}, \texttt{lt}, \texttt{lte}, \texttt{gt}, \texttt{gte}, \texttt{in}, \texttt{nin}) a~hledanou hodnotou. Dodáním implementace podporující ostatní logické operátory \texttt{OR}, \texttt{NOT} a~\texttt{NOR}, by šlo vytvářet složitější dotazy bez nutnosti transformace dotazu pouze na spojení pomocí \texttt{AND}.

\subsubsection{Klientská aplikace s~grafickým rozhraním}
Systém distribuovaného úložiště lze ovládat pomocí mnoha parametrů, lze specifikovat příkazy, umístění vstupních dat, názvy front, a~v~neposlední řadě také variabilní kritéria pro dotazování. Dodaná klientská aplikace představuje jednoduchý demonstrativní nástroj, který lze spustit z~příkazové řádky. Zahrnuje pouze malou podmnožinu případů použití celého systému, napevno zadaná kritéria pro dotazování, a~také neobsahuje párování zpráv požadavků a~odpovědí pomocí ID.

V~klientské aplikaci s~grafickým rozhraním by mělo jít intuitivně sestavit zprávu požadavku výběrem parametrů a~odeslat danou zprávu. Grafické rozhraní by mělo umožnit přidávání dotazovacích kritérií podle typu forenzních dat. Párování zpráv požadavků a~odpovědí podle ID zpráv lze realizovat v~přehledné tabulce.

\subsubsection{Monitorování odchozích a~příchozích zpráv}
Jedná se zase spíše o~rozšíření klientské aplikace, souvisí s~párováním zpráv pomocí ID. Odchozí i~příchozí zprávy by mohly být zaznamenávány do databáze a~svázány vztahem přes společná ID.

%=========================================================================
