Buenas, tengo instalado un pequeño cluster de 6 mv y ahora voy a migrar a un servidor con mas recursos. El anterior cluster tenia destinados pocos recursos por maquina y ahora, en una etapa de verificacion de pruebas, quisiera acercarme los mas posible a lo que sera el modelo a implementar.
Algunas certezas que tengo son que los node.data requieren mas CPU y memoria de almacenamiento.
Lo ideal seria tener al menos 3 nodos de datos y 2 nodos clientes, para tener redundancia.
Entre las dudas están,
conviene tener menos node.data de mayor capacidad de almacenamiento o varios mas pequeños. Puntualmente, 4 de 3 TB o 6 de 2TB.
A la hora de asignar RAM, esto no lo tengo tan claro... en el cluster que actualmente esta operando los recursos san tan pocos que el consumo es bastante alto de manera permanente y las diferencias no son muchas. Veo un mayor uso en los node.data y node.client , nada mas. La disponibilidad que tengo me permite asignar unos 10GB por nodo, pero quiero optimizar el uso del recurso.
Cuando se habla de uso de CPU intensivo en los nodos de datos no ahy un requerimiento minimo, supongo que tendra que ver con la escala de cada proyecto. Las dimensiones de la informacion que se almacenaran entiendo estaran alrededor de los 120 indices diarios nuevos y probablemente unos 50 que serian relativamente "estaticos".
Slds y muchas gracias desde ya al que pueda aportar su experiencia.
Emiliano
Depende mucho del proyecto y de la prevision de carga de datos. Siempre se inicia con muy poca data pero al cabo de un mes o mas el incremento suele ser muy grande.
Eso lo tienes que tener en cuenta.
Efectivamente, los data nodes se encargan de las operaciones de indexing y search por tanto tienen que tener unas especificaciones de HW mas potentes (a nivel de RAM y CPU). Si ademas esos nodes van tener el role de master (es decir no usas master dedicados) todavia mas potentes tiene que ser.
Los client nodes, no necesitan tener un storage muy grande: no almacenan datos. Ahora bien, si usas agregaciones (especialmente desde KIbana) complejas, si te interesan que a nivel de CPU y RAM sean potentes (casi como un data node).
La preferencia seria tener varios data nodes de talla media que un par de data nodes con mucha RAM/CPU.
Es importante que hagas tests para comprobar la capacidad de uno de tus nuevas maquinas. Por ejemplo, puedes tomar una, crear un index con 1 shard (pero sin replicas) y empezar a indexar y hacer busquedas. Habra un momento en que veras que o bien la respuesta de las busquedas o bien la velocidad de indexacion es notablemente mas lenta.
Hay tendras el punto critico/limite de tu maquina (eso tambien te dara la talla del tu shard/index). A partir de ahi, puedes extrapolar a las otras nuevas maquinas (añadiendo replicas,etc)
Con respecto al storage, tienes que tener claro cuanto tiempo vas a almacenar los datos (15 dias, un mes,etc) para saber la talla de disco que necesitaras.
Para data nodes, diria que entre 8-16 CPU cores (al menos) y a partir de 16Gb de RAM (en sistemas de produccion). Eso es para que te guies, tu proyecto podria funcionar con menos recursos, en funcion de tus necesidades. Pero siempre piensa en prevenir el aumento de carga de datos
Confiamos en que esta info te ayude en tu planificacion!
Muchas gracias @miguel, es de mucha ayuda.
Algunas de las cosas que me comentas ya las probé, hace varios meses que tengo un cluster estable pero de dimensiones mucho mas pequeñas, manejando alrededor de 20 indices abiertos simultáneamente y realizando algunas operaciones con Kibana (algun dashboard abierto permanentemente, y otras consultas puntuales como para probar el comportamiento), y mas de 8600 indices en total. Esto se debe a que las limitaciones de recursos hacia inviable tener indices mas grandes, no podía manejarlos la Heap.
En el esquema previsto la información es almacenada de manera permanente, pero en la segunda etapa sumaria al cluster un storage al cual haria los snapshot y despues liberaría la información mas vieja de los nodos de datos... de todas formas estaríamos hablando de datos con al menos 1 año de antiguedad. Con estos nuevos recursos voy a ver cuan grande pueden ser los indices, ya que estoy creandolos por dia (y seguiria asi) y cerrando los anteriores
.
Los node.master van a ser dedicados y pensaba usar 3, configurando en minimum_master_nodes = 2 para evitar split brain. Por mi experiencia los recursos que utiliza son menores que los node.data e ingest ...
Una duda que tengo, creo que lo lei en el manual pero ahora no lo encuentro, es la cantidad de replicas y shards a realizar-configurar... la cantidad afecta afecta al rendimiento y cual seria el punto de equilibrio (o como calcularlo) a la hora de evaluar confiabilidad (resguardo de información) y rendimiento?
Muchas gracias por la información que me brindaste en la respuesta anterior, es de suma utilidad.
No hay de que!
Con respecto a calcular el número ideal de shards te dejo este enlace:
En realidad no existe una especie de benchmark general y depende de cada caso. Hay detalles de optimización como por ejemplo no crear más shards primarios que el número de data nodes que tienes. En realidad tendrias que crear un solo data node, (indices con 1 solo shard) y empezar a indexar cómo lo harías en producción. Ahi tendrias que vigilar la velocidad de indexación y la velocidad de respuesta...hasta un momento dado en el que o bien una, bien la otra otra o ambas no responden al nivel que es aceptable para tu caso. Ese sera tu limite para ese data node).
A partir de ahí, escalas a dos nodes e indices con una replica, etc-etc.
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.
