L'approccio migliore per specificare gli host ZooKeeper sui client Solr?

Question

Abbiamo alcune configurazioni di SolrCloud & ZooKeeper in esecuzione in AWS EC2 e, per la maggior parte, funzionano senza problemi, ma dopo un recente errore di uno dei nostri nodi ZooKeeper ho iniziato a chiedermi se un metodo con cui i client risolvono il problema ZooKeepers era migliore di altri. I nostri client sono basati su java usando il client java di Solr 4.1.

Originariamente stavamo usando le voci hostfile per identificare gli ZooKeepers, ma assicurandomi che le voci in /etc/hosts fossero aggiornate data la natura di AWS, è diventato molto noioso farlo. Quindi ora stiamo utilizzando il DNS personalizzato tramite Route53 per identificare invece ZooKeepers. Ma stiamo ancora individuando i nodi Zookeeper singolarmente, in modo ad esempio che attualmente specificarlo al momento di lanciare i nostri clienti:

-Dsolr.zookeeperHosts='zk-1.mydomain.com:2181,zk-2.mydomain.com:2181,zk-3.mydomain.com:2181' 

I padroni di casa zk-1.mydomain.com ecc, sono semplicemente CNAME'd al DNS per ogni istanza ZooKeeper EC2. Così ora, se Amazon ci obbliga a riavviare uno ZooKeeper, che provoca l'ottenimento di un nuovo indirizzo IP, il client riceverà il nuovo IP quando il record DNS viene aggiornato.

La mia domanda ha a che fare con la domanda se c'è un approccio ancora migliore da prendere nella gestione di questo. Supponiamo di voler aggiungere altri ZooKeeper al mix, quindi abbiamo avuto un quorum di 5 nodi anziché di 3. (In realtà vorrei farlo.) Avrebbe più senso avere un singolo record DNS robin round che contenga tutto il ZooKeepers in esso e passa quel singolo nome DNS al client?

Ad esempio, impostare il record DNS zookeepers.mydomain.com come un CNAME che punti a zk-1.mydomain.com, zk-2.mydomain.com e zk-mydomain.com e poi semplicemente pas questo per i miei clienti:

-Dsolr.zookeeperHosts='zookeepers.mydomain.com:2181' 

In questo modo, quando ho aggiungere nuovi guardiani dello zoo al cluster Potrei semplicemente aggiungere un altro record CNAME a zookeepers.mydomain.com e non preoccuparti di aggiornare le configurazioni su tutti i client.

Il client Solr è abbastanza intelligente da utilizzare un record DNS con più record al suo interno? In particolare, se uno ZooKeeper risulta inattivo e il client tenta di connettersi ad esso, il client ne saprà abbastanza da richiedere di nuovo il DNS per ottenere l'IP del prossimo ZooKeeper e tentare di comunicare con esso?

Answer 1

L'utilizzo di CNAME è una buona idea, ma suggerisco di estenderlo con gli IP Elastic per renderli più robusti, le modifiche DNS richiedono tempo per propagare Elastic IPS sono molto più reattive.

Comunque ho qualche avvertimento, nelle nostre indagini abbiamo cercato di esplorare come reagirebbe Zookeeper/Solr se invece di usare nomi/host host abbiamo usato un bilanciamento del carico e lo abbiamo dato a Solr NON FARE QUESTO! Sembra che internamente identifichi ogni voce solr.zookeeperHosts come server zookeeper e quando uno non è riuscito per qualche motivo lo ha invalidato, dal punto di vista di Solr non c'erano altri server Zookeeper quindi Solr non era inattivo. La mia ipotesi è che avrete lo stesso problema avendo un record con diversi IP.

La soluzione migliore è automatizzare il più possibile. In un precedente progetto ho utilizzato lo chef per raccogliere tutti i nodi dello zoo e impostare ips/hostname dinamicamente su ciascun nodo solr. Se lo chef è un grande cambiamento per te, lo stesso può essere fatto usando i tag EC2 e alcuni abili script di bash. Puoi contrassegnare le istanze di Zookeeper con un tag e utilizzare il codice aws in questo modo per ottenere un elenco di ips.

ec2-describe-instances --filter "tag-key=Zookeeper"