W dzisiejszych czasach usługi informatyczne zdominowały zarówno świat biznesu, jak i prywatne życie zwykłych ludzi. Internet spopularyzował systemy komputerowe do tego stopnia, że zaczynają one wypierać tradycyjne metody przetwarzania informacji ze wszystkich dziedzin życia. W świecie WWW można skorzystać ze słownika, obejrzeć mapy, szybko i komfortowo wyszukać dowolne interesujące nas dane.
Jak łatwo się domyśleć wraz z popularnością systemów informatycznych wzrosła liczba ich potencjalnych użytkowników, co bezpośrednio wiąże się z potrzebą zwiększenia mocy obliczeniowej. Firmy prześcigają się w ofertach dużych, wieloprocesorowych maszyn, które umożliwiłyby obsługę tysięcy czy nawet milionów użytkowników na sekundę. Niestety koszt takiej maszyny bardzo często przekracza budżet małych czy średnich firm, które mają dobre pomysły, ale brakuje im odpowiednich funduszy, aby je zrealizować. W takiej sytuacji idealnym rozwiązaniem może okazać się połączenie wielu zwykłych, niedrogich komputerów, które wspólnie umożliwią obsługę dużej liczby klientów. Aby taka architektura mogła rozwiązać problem zwiększonego zapotrzebowania na moc obliczeniową w sposób niewidoczny dla końcowego użytkownika, niezbędne jest odpowiednie oprogramowanie.
W swojej pracy przedstawię pomysł stworzenia modułu wspierającego rozproszone przetwarzanie danych (klaster) dla bardzo popularnego serwera WWW – Jakarta-Tomcat. W pierwszej części zostanie przedstawiona koncepcja klastra (por. rozdz. 2) oraz opisany sposób działania Tomcata (por. rozdz. 3). W drugiej części pracy przedstawię zrealizowany przeze mnie moduł klastra (por. rozdz. 4) wraz z testami jego wydajności (por. rozdz. 5). Możliwe rozszerzenia opisuję w rozdz. 6.
W pracy prezentuję pozytywne strony wykorzystania modelu replikowania „każdy do każdego”. Wykazuję, że dobrze zaimplementowany moduł może okazać się bezpieczniejszy i wydajniejszy od modelu „serwer macierzysty, serwer kopii”. Oczywiście implementacja jest znacznie bardziej skomplikowana (pojawia się problem synchronizowania dostępu do sesji) – niemniej jednak zysk jaki można osiągnąć stosując ten model w przypadku protokołu HTTPS rekompensuje trudy implementacji modułu.