amięci RAM. Systemem operacyjnym będzie GNU/Linux CentOS 7. Na dane przeznaczymy ok. 10 GB, biorąc pod uwagę konieczność pozostawienia miejsca dla systemu operacyjnego.

Pierwszym etapem projektowania jest stworzenie tabeli na wzór \ref{tab:sample_clusterplan}. Biorąc pod uwagę to że wszystkie węzły są równorzędne, przestrzeń wartości (równą $2^{64}$) można rozdzielić między nie równo. Wyniki tego etapu zamieszczono w tabeli \ref{tab:example_clusterplan}.

\begin{table} \centering \begin{tabular}{|c|c|c|}
\hline IP & Miejsce na dane & Wartość przedziału \\ \hline
192.168.224.100 & 10 GB & -9223372036854775808 \\
192.168.224.101 & 10 GB & -3074457345618258604 \\
192.168.224.102 & 10 GB & 3074457345618258601 \\
\hline \end{tabular}
\caption{Projekt klastra testowego (przykładowego)} \label{tab:example_clusterplan} \end{table}

Kolejnym krokiem jest ustalenie grafu węzłów startowych. Ze względu na prostotę tej instalacji można określić jeden węzeł startowy --- niech będzie nim 192.168.224.100. Pozostałe węzły będą się łączyć do niego celem początkowej,,koordynacji``.

Po instalacji docelowego oprogramowania na maszynach przeprowadzono ich konfigurację. Była ona na wszystkich węzłach podobna, wystąpiły jedynie różnice w adresacji IP interfejsów oraz początków przedziałów. Drugą istotną różnicą było uzupełnienie ustawień węzła startowego w 192.168.224.101 i 192.168.224.102. Konfigurację przedstawiono na rysunku \ref{fig:example_config}. Konfigurację 192.168.224.102 utworzono analogicznie.

Teraz należy przeprowadzić uruchomienie węzłów. Jako pierwszy powinien zostać uruchomiony węzeł 192.168.224.100. Jest to wymagane, gdyż węzły które będą uruchamiane później muszą być się w stanie z nim połączyć\footnote{celem uproszczenia wywodu wcześniej poprawnie skonfigurowano firewall. Opis tej operacji wykracza poza temat ninejszej pracy.}. Tak więc węzły uruchomiono w kolejności 100, 101, 102. Wraz z każdym uruchomieniem możemy obserwować jak wszystkie węzły aktualizują swoją bazę danych, wykrywając nowe węzły. Większą pauzę (kilka sekund) zaobserwować można między startem 102 a wykryciem go przez 101, co związane jest z tym że propagacja przez węzeł 100 może zająć do 4 sekund. Stan konsoli po uruchomieniu węzła 101 w momencie gdy informacje są już rozesłane przedstawia rysunek \ref{fig:after_101_start}.

	\begin{figure}[h]
		\centering \includegraphics[width=15cm]{example_config}
		\caption[Przykład konfiguracji dwóch węzłów]{Konfiguracja dwóch węzłów. Po lewej stronie konfiguracja 192.168.224.100, po prawej 192.168.224.101.}
		\label{fig:example_config}
	\end{figure}

	\begin{figure}[h]
		\centering \includegraphics[width=15cm]{after_101_start}
		\caption[Zrzut ekranu konsoli węzła]{Konsola węzła 192.168.224.101 po uruchomieniu węzła 192.168.224.102. Węzeł najpierw,,odkrywa`` siebie samego (101), później odkrywa węzeł startowy (100) gdy łączy się do niego, a na samym końcu otrzymuje informację o węźle 102, który dołączył do klastra jako ostatni.}
		\label{fig:after_101_start}
	\end{figure}

W tym momencie --- czyli gdy każdy węzeł wie o każdym --- klaster gotów jest do pracy w roli bazy danych systemu kontrolno-pomiarowego, a węzły oczekują na komendy.

Zatrzymania programu dokonuje się poprzez wymuszone,,zabicie`` procesu. Program jest zaimplementowany jako \textit{crash-only software}\cite{Candea:2003}, to jest oprogramowanie którego jedynym sposobem zatrzymania jest nagłe i wymuszone przerwanie pracy. Przerwanie pracy programowi w dowolnej chwili, czy to przez awarię czy przez zatrzymanie z woli użytkownika, nie grozi nieodwracalnym uszkodzeniem danych.

Skonfigurowany tutaj przykładowy klaster posłuży później do testów.

	\subsection{Naprawa klastra i węzła} \label{sec:cluster_repair}
W pracy klastra może wydarzyć się sytuacja, że jeden z węzłów ulegnie awarii i przestanie reagować na komendy. Może być to związane z awarią sprzętową lub programową na systemie działającym jako węzeł.

Niezależnie od przyczyny awarii, obsługa bazy w przypadku awarii jest bardzo prosta. Sama usterka może być dłuższy czas niezauważona, ze względu na wbudowaną tolerancję na awarie węzłów klastra. Z tego powodu zalecane jest korzystanie z zewnętrznych narzędzi monitorujących pracę poszczególnych węzłów. Są one standardowymi elementami wdrożenia systemów klastrowych.

Pamiętać należy o tym, że jedynym elementem identyfikującym węzeł w systemie jest początek jego przedziału odpowiedzialności. Inne węzły potraktują nawet nowy komputer, legitymujący się tą samą wartością przedziału, jako stary element klastra.

Gdy awaria została już usunięta na poziomie sprzętowo-systemowym, tj. jednym elementem który należy przywrócić jest działanie procesu bazy danych, należy rozpatrzyć czas awarii. Inny