Solr jest jednym z kluczowych elementów platformy Sitecore xDB, ułatwiającym zarządzanie indeksami wyszukiwania. Dzięki Solr indeksy nie muszą być przechowywane bezpośrednio na serwerach CD i CM (tak jak w Lucene). Ponieważ w Sitecore jest dużo zależności do tych indeksów (wyszukiwanie item’ów, Sitecore Analytics, itd.) bardzo ważne jest zapewnienie wysokiej wydajności i dostępności usługi, tak żeby Solr nie był wąskim gardłem w dużej produkcyjnej implementacji Sitecore’a. Są dwa sposoby na ustawienie wieloserwerowego produkcyjnego środowiska Solr: replikacja Master-Slave i SolrCloud. Jakie są ich wady i zalety?
- Replikacja Master-Slave
- W miarę prosta konfiguracja
- Automatyczna replikacja indeksów
- Automatyczne przełączanie na inny serwer w razie awarii dla wyszukiwania indeksu (wymaga load balancer’a)
- Brak obsługi automatycznego przełączania awaryjnego dla uaktualniania indeksów
- Poprawiona wydajność podczas wyszukiwania
- Stare rozwiązanie, zastępowane przez SolrCloud
- SolrCloud
- Bardziej skomplikowane rozwiązanie, wymaga dodatkowych serwerów dla ZooKeeper
- Automatyczna replikacja indeksów
- Automatyczne przełączanie na inny serwer w razie awarii dla wyszukiwania i uaktualniania indeksu
- Poprawiona wydajność podczas wyszukiwania
- Nowe rozwiązanie, wspierane eksperymentalnie od Sitecore 8.2, lub niestandardowe rozwiązanie (wymaga load balancer’a)
Sitecore i replikacja Solr Master-Slave
Żeby stworzyć produkcyjne środowisko Solr potrzebujemy minimum dwóch serwerów: Master i Slave. Rolą instancji Master jest uaktualnianie i odczyt indeksów. Instancja Slave może być użyta tylko do odczytu indeksów. Dodatkowo Slave cyklicznie odpytuje serwer Master o najnowszą wersję indeksów i jeśli pojawią się nowe, indeksy są replikowane z Master do Slave. Co stanie się jeśli uaktualnimy indeks bezpośrednio na instancji Slave? Sitecore pozwoli nam na to, ale indeksy na obu serwerach nie będą zsynchronizowane. Solr będzie miał inną wersję indeksu na serwerach ponieważ nie jest możliwe uaktualnienie indeksu z Slave do Master.
W praktyce oznacza to że możemy ustawić tylko jedną instancję Solr, na której Sitecore może uaktualniać indeksy, więc bezawaryjność będzie tylko częściowa. Możemy zapewnić, że odczyt indeksów będzie działał w razie awarii (load balancer skieruje ruch na serwer Slave jeśli Master ulegnie awarii), ale nie możemy, bez niestandardowego rozwiązania, zapewnić działania uaktualniania indeksów, w razie awarii serwera Master (na przykład, jeśli Master przestanie działać, strona oparta Sitecore również powinna wciąż być dostępna, włącznie z wyszukiwaniem na stronie, ale treści stworzone po awarii, nie będą dostępne w wyszukiwarce). Dodatkowo w tej konfiguracji możemy stworzyć więcej serwerów Slave, co dodatkowo poprawi wydajność.
Ważną częścią opisanej konfiguracji jest load balancer. Musimy skonfigurować go w ten sposób, aby odczyt indeksu (żądania HTTP GET) były kierowane do wszystkich serwerów Solr, a uaktualnianie indeksów (żądania HTTP POST) kierowane tylko do serwera Master.
Konfiguracja replikacji indeksu na Solr Master
Aby skonfigurować replikację indeksów na serwerze Solr Master musimy zmienić plik solrconfig.xml (plik znajduje się w katalogu definicji każdego indeksu \server\solr\sitecore_master_index\conf\):
|
1 2 3 4 5 6 7 8 |
<requestHandler name="/replication" class="solr.ReplicationHandler" > <lst name="master"> <str name="replicateAfter">startup</str> <str name="replicateAfter">commit</str> <str name="confFiles">schema.xml,stopwords.txt,elevate.xml</str> <str name="commitReserveDuration">00:00:10</str> </lst> </requestHandler> |
Krok powtarzamy dla wszystkich indeksów.
Konfiguracja replikacji indeksu na Solr Slave
Aby skonfigurować replikację indeksów na serwerze Solr Slave musimy zmienić plik solrconfig.xml. Krok powtarzamy dla wszystkich indeksów na serwerze Slave:
|
1 2 3 4 5 6 |
<requestHandler name="/replication" class="solr.ReplicationHandler" > <lst name="slave"> <str name="masterUrl">http://smartsitecore-solr-master:8983/solr/${solr.core.name}</str> <str name="pollInterval">00:00:20</str> </lst> </requestHandler> |
Połączenie Sitecore’a do Load Balancer’a i przetestowanie rozwiązania
Uaktualnimy adres Solr w Sitecore za pomocą prostego patch’a:
|
1 2 3 4 5 6 7 8 9 |
<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/"> <sitecore> <settings> <setting name="ContentSearch.Solr.ServiceBaseAddress"> <patch:attribute name="value">http://smartsitecore-solr:8983/solr</patch:attribute> </setting> </settings> </sitecore> </configuration> |
Adres powinien wskazywać na Load Balancer. Teraz jesteśmy gotowi żeby przetestować rozwiązanie. Po przebudowaniu indeksów w panelu sterowania Sitecore’a logujemy się do konsoli administracyjnej Solr na serwerach Master i Slave. Powinniśmy wiedzieć te same wersje inkdesów Sitecore’a na instacji Master:
oraz na instancjach Slave:
Sitecore i SolrCloud
SolrCloud to nowocześniejsze sposób na stworzenie klastra Solr o wysokiej wydajności i odporności na awarie. Ułatwia dodatkowo konfigurację replikacji indeksów na wielu maszynach i index sharding.
- Replikacja indeksów: tworzenie kopii całego indeksu na innej instancji Solr. Używane w celu poprawy wydajności i dostępności usługi.
- Index sharding: podział indeksu na kilka instancji Solr. Używane w celu poprawy wydajności, jeśli indeks jest zbyt duży żeby obsługiwać go na pojedynczej maszynie.
SolrCloud dodatkowo zapewnia automatyczne przełączanie na inny serwer w razie awarii, dla wyszukiwania po indeksie (dzieląc zapytania na różne instancje Solr) oraz dodatkowo dla uaktualniania indeksów. Uaktualnianie indeksów w SolrCloud odbywa się na jednej z instancji z klastra nazywanej Leader. SolrCloud używa dodatkowo ZooKeeper do monitorowania stanu i globalnej konfiguracji klastra oraz nominowania nowej instancji Solr w razie awarii Leader’a. Ponieważ to jest główną rolą ZooKeeper’a nie potrzebuje on maszyny o dużej mocy.
Sam ZooKeeper musi także być zainstalowany na większej ilości maszyn żeby obsłużyć awarie. Oficjalny poradnik mówi o “Aby stworzyć architekturę, która obsłuży awarię F maszyn, potrzeba zainstalować ZooKeeper na 2xF+1 maszynach”. W praktyce żeby obsłużyć jedną awarię potrzeba minimum 3 instancji ZooKeeper.
W idealnym scenariuszu ZooKeeper powinien być zainstalowany na odrębnych maszynach, lecz by zredukować liczbę serwerów można go zainstalować na tych samych maszynach co Solr (sugeruje się jednak użycie odrębnych dysków twardych), więc podsumowując achitektura wygląda w następujący sposób:
Ponownie jedyną zmianą, potrzebną w Sitecore jest wskazanie na Load Balancer w “ContentSearch.Solr.ServiceBaseAddress”. Jeśli chcesz się dowiedzieć więcej na ten temat, zapraszam do przeczytania serii artykułów o konfiguracji SolrCloud, których autorem jest Chris Sulham:
http://www.chrissulham.com/sitecore-on-solr-cloud-part-1
Pingback: Sitecore – howtos and useful links – Angel's Place()