Zookeeper Apache: dystrybucja węzłów w centrach danych

Question

Pracuję nad zupełnie nową infrastrukturą SolrCloud - ZooKeeper.

Niektóre informacje tła:

• wszystkie inne usługi (głównie infrastruktura web site) są rozłożone dwa centra danych, z aktywny aktywnych konfiguracjach.
• na poziomie sieci, serwery są skonfigurowane na rozszerzonej sieci LAN, z ciemnym światłowodem w centrach danych. Tak więc opóźnienie jest minimalne.
• W większości tych aplikacji będzie używana infrastruktura SolrCloud - ZooKeeper.

Mam Chmurę Solr i działający zespół ZooKeeper. Wdrożenie na tym poziomie jest w porządku.

Ale zastanawiam się, jak rozpowszechniać moje serwery ZooKeeper. Muszę mieć nieparzystą liczbę serwerów, ale mam tylko dwa centra danych. Jeśli się nie uda, mam 50-50 szans, że stracę większość.

Wszelkie pomysły? Do tej pory myślałem o: (! Nie może się zdarzyć, $$$)

• zainteresowanie trzecią centrum danych

• gospodarz 2 za centrum danych i 1 na zewnętrznym dostawcą Cloud (Amazon lub ...?). Ponownie $$$

• ustaw nieparzystą liczbę w centrum danych 1 i użyj obserwatora na stronie 2. Co się stanie, jeśli witryna 1 się nie powiedzie? Czy SolrCloud może współpracować tylko z jednym obserwatorem?

Dziękuję za wszelkie pomysły i uwagi.

Nic

Answer 1

Dawno temu, ale nadal, podzielmy się tym, co zrobiłem.

Mam trzecią witrynę, na której można umieścić drugą instancję ZooKeepera. Ta strona jest innym biurem mojej firmy, a nie "pełnym DC". Więc każda strona ma 1 ZK.

Co pozwoliło mi mieć jeden klaster rozłożony na 3 DC, to że są one wystarczająco blisko siebie, aby uzyskać między nimi ciemne włókno. Opóźnienie jest bardzo niskie i nie wpływa na wydajność ZK.

Następnie dla SOLR, dostałem pełne repliki na dwóch głównych DC. W trzecim biurze odbywa się tylko kwizum ZK. Używając pełnych replik, mam wszystkie dane w każdym DC. Jeśli moje potrzeby SOLR wzrosną później, odejdę, ale na razie nasz indeks jest mały.

Sprawdził się solidnie od 4 lat, z 1 awarią. I to było w trzecim biurze, a nie w DC.

Answer 2

Jeśli wymogiem jest służyć wszystkich żądań wyszukiwania z lokalnym centrum danych (w którym wniosek został pochodzenie), wtedy nie trzeba iść do cross rozmieszczenia dc zk. Przyczyna wdrożenia cross dc zk wymagane tylko po to, aby przetrwać awarię DC (najprawdopodobniej nie nastąpi, i dlatego płacisz $$$$), więc w tym przypadku nie ma potrzeby odradzania się klastra zk w wielu DC