SolrCloud HOWTO

Co jest najważniejszą zmianą w wersji 4.x Apache Solr? Myślę, że takich zmian jest wiele, ale SolrCloud jest czymś, co zdecydowanie zmienia architekturę wdrożeń. Do tej pory większe instalacje użerały się z problemem  single point of failure (SPOF) – istniał tylko jeden serwer master i gdy ten serwer ulegał uszkodzeniu, cały cluster tracił zdolność przyjmowania nowych danych. Oczywiście można było próbować opcji z wieloma serwerami master, gdzie pojedynczy serwer był odpowiedzialny tylko za część danych, ale ciąle SPOF był obecny. Nawet, gdy wszystko działało poprawnie, ze względu na odstęp między operacjami commit, oraz ze względu na fakt, że instancje slave sprawdzały dostępność nowych danych co pewien okres, rozwiązanie było dalekie od ideału – nowe dane były widoczne dopiero po paru(nastu) minutach.

Solr Cloud to zmienił. W tym artykule zainstalujemy nowy cluster SolrCloud „od zera” i zobaczymy jak to działa w praktyce.

Nasz przykładowy cluster

W przykładach będziemy używać trzech serwerów Solr. Każdy serwer w clustrze jest zdolny obsługiwać jednocześnie indeksowanie oraz zapytania. To podstawowa różnica w stosunku do wcześniejszego rozwiązania z jednym serwerem master i wieloma serwerami slave. W nowej architekturze pojawia się dodatkowy element: Zookeeper, odpowiedzialny za przechowywanie konfiguracji clustra i synchronizacje jego pracy. To jest bardzo ważna informacja oznaczająca, że gdy Zookeeper zawiedzie, cały cluster jest bezużyteczny. Z tego powodu niezbędne jest zapewnienie wysokiej dostępności tego elementu – dlatego w tym przykładzie używamy trzech niezależnych instancji Zookeepera.

Instalacja Zookeepera

Jak napisaliśmy wcześniej, Zookeeper jest istotną częścią rozwiązania SolrCloud. Mimo, że możemy używać Zookeepera wbudowanego w Solr, jest to przydatne w zasadzie tylko w testowaniu. Do rozwiązań produkcyjnych zdecydowanie potrzebujesz, by Zookeeper był zainstalowany niezależnie od Solr i działał w innym procesie JVM by wyeliminować możliwość wzajemnego wpływu na swoją pracę lub przerwę w działaniu.

Instalacja Apache Zookeeper jest całkiem prosta i może być opisana następującymi krokami:

  1. Pobranie archiwum Zookeeper z: http://www.apache.org/dyn/closer.cgi/zookeeper/
  2. Rozpakowanie pobranej paczki i skopiowanie conf/zoo_sample.cfg do conf/zoo.cfg
  3. Modyfikacja zoo.cfg:
    1. Zmiana dataDir na katalog, gdzie chcesz przechowywać dane konfigracyjne generowane przez cluster
    2. Dodanie informacji o wszystkich instancjach Zookeepera (patrz niżej)

Po wspomnianych zmianach mój zoo.cfg wygląda następująco:

tickTime=2000
initLimit=10
syncLimit=5
dataDir=/var/zookeeper/data
clientPort=2181
server.1=zk1:2888:3888
server.2=zk2:2888:3888
server.3=zk3:2888:3888

Następnie:

  1. Skopiuj instalacje na wszystkie serwery, gdzie Zookeeper ma działać
  2. Stwórz plik /var/zookeeper/data/myid z indentyfikatorem serwera. Identyfikator ten jest różny dla każdej instancji (np. dla maszyny  zk2  ten plik będzie zawierał liczbę:  2 )
  3. Uruchom wszystkie instancje używając polecenia “bin/zkServer.sh start-foreground” i zweryfikuj poprawność instalacji
  4. Dodaj “bin/zkServer.sh start” do skryptów startowych i upewnij się, że system operacyjny monitoruje dostępność instancji Zookeepera.

Instalacja Solr

Instalacja Solr jest następująca:

  1. Pobierz archiwum Solr z: http://www.apache.org/dyn/closer.cgi/lucene/solr/4.1.0
  2. Rozpakuj pobrany plik
  3. W tym artykule będziemy używać gotowej instalacji z katalogu example i wszystkie zmiany będziemy wykonywać na tej przykładowej instalacji
  4. Skopiuj instalację Solr na wszystkie serwery będące częścią clustera
  5. Zainstaluj do Zookeepera dane konfiguracyjne, które będą używane przez cluster. W tym celu uruchom pierwszą instancję Solr z:
    java -Dbootstrap_confdir=./solr/collection1/conf -Dcollection.configName=solr1 -DzkHost=zk1:2181 -DnumShards=2 -jar start.jar

Ta komenda powinna być wykonana tylko raz. Następne uruchomienia będą używać konfiguracji z Zookeepera i lokalna konfiguracja nie jest już potrzebna. Następnie:

  1. Uruchom wszystkie instancje Solr używając:
    java –DzkHost=zk1:2181 –jar start.jar

Sprawdzenie poprawności instalacji

W tym celu idź do panelu administracyjnego na dowolnej instancji Solr. W naszym przykładzie URL jest następujący:  http://solr1:8983/solr. Gdy klikniesz na zakładce: cloud a następnie wybierzesz graph, powinieneś zobaczyć coś podobnego do poniższego obrazka:

cloud

Kolekcja

Nasz pierwsza kolekcja – collection1 jest podzielona na dwa shardy  (shard1 i shard2). Każdny z nich jest umiejscowiony na dwóch instancjach Solr (OK, na obrazku widzisz, że każdy Solr jest na tej samej maszynie fizycznej  – Mam aktualnie tylko jeden fizyczny serwer do testów – może jakiś ochotnik do darowizny?  ;)). Możesz też zobaczyć patrząc na grafikę kropki czy to jest primary shard czy replika.

Podsumowanie

Mam nadzieję, że to pierwszy z serii wpisów na temat solrCloud. Wiem, że jest bardzo krótki i pomija pewne detale i informację o shardach, replikach i architekturze rozwiązania. Potraktuj to jako checklistę do prostej (ale rzeczywistej) konfiguracji swojego rozwiązania „chmurowego”.

This post is also available in: angielski

This entry was posted on poniedziałek, Marzec 11th, 2013 at 09:04 and is filed under Solr. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.