Zookeeper: Wait-free Coordination for Internet-scale Systems
1 recomendación702 vistas
El documento describe a ZooKeeper, un servicio de coordinación distribuida que permite implementar primitivas como configuraciones, membresía de grupos y locks de forma no bloqueante. ZooKeeper garantiza propiedades como escrituras linealizables, orden FIFO y disponibilidad a pesar de fallas a través de su arquitectura de procesamiento de pedidos, broadcast atómico y base de datos replicada.
Zookeeper: Wait-free Coordination for Internet-scale Systems
- 1. Zookeeper1 : Wait-free Coordination for Internet-scale Systems P. Hunt M. Konar F. Junqueira B. Reed 10 de julio de 2012 Por: Leandro Lera Romero 1 Because Coordinating Distributed Systems is a Zoo
- 2. ´ ¿Como nos organizamos? Las aplicaciones distribuidas requieren diferentes formas de coordinaci´n. o Configuraci´n. o Pertenencia a un grupo (Group Membership). Elecci´n del lider. o 1 / 23
- 3. ´ ¿Como nos organizamos? Una opci´n es desarrollar servicios para cada necesidad. o Amazon Simple Queue Service. The Akamai configuration management system. Otra alternativa es utilizar un servicio de locking para sistemas distribuidos. Necesitamos algo que nos de mayor flexibilidad. 2 / 23
- 4. El que espera, desespera El objetivo es dise˜ar un servicio de coordinaci´n distribuida que: n o Sea capaz de adaptarse a diferentes problem´ticas. a Permita a los desarrolladores implementar sus primitivas. Evite el uso de locks, o primitivas bloqueantes. 3 / 23
- 5. El que espera, desespera El objetivo es dise˜ar un servicio de coordinaci´n distribuida que: n o Sea capaz de adaptarse a diferentes problem´ticas. a Permita a los desarrolladores implementar sus primitivas. Evite el uso de locks, o primitivas bloqueantes. En definitiva, necesitamos un coordination kernel que exponga una API que sea wait-free. 3 / 23
- 6. Los componentes de ZooKeeper ZooKeeper est´ conformado por los siguientes componentes: a Servidores Clientes Sesi´n o zNodos Regular Ef´ ımero API Watches 4 / 23
- 7. La API Algunos de los m´todos fundamentales: e create(path, data, flags) delete(path, version) exists(path, watch) getData(path, watch) setData(path, data, version) getChildren(path, watch) sync(path) 5 / 23
- 8. ZooKeeper garantiza Escrituras linealizables: todos los pedidos de actualizaci´n o del estado de ZooKeeper son serializados y respetan el orden de precedencia. Orden de cliente FIFO: todos los pedidos de un cliente son ejecutados en el orden en el que fueron env´ ıados. Liveness: el servicio est´ disponible mientras haya una a mayor´ de servidores activa y comunicada. ıa Durabilidad: los cambios persisten, a pesar de fallas, si en alg´n momento se recupera la mayor´ de servidores. u ıa 6 / 23
- 9. Algunas primitivas: Configuraciones 1. Definimos un zNodo Zc en donde se almacenar´n las a configuraciones. 2. Los procesos cuando arrancan leen la configuraci´n. o getData(Zc , TRUE ) 3. Si se produce alguna modificaci´n vuelven al paso 2. o 7 / 23
- 10. Algunas primitivas: Group Membership 1. Definimos un zNodo Zg que representa al grupo. 2. Los procesos cuando arrancan crean un zNodo ef´ ımero, con un nombre unico, como hijo de Zg . ´ create(Zg + “/”, data, ephemeral | sequential) Los procesos pueden obtener informaci´n del grupo viendo los hijos o de Zg . En caso de que el proceso termine o falle, el nodo creado es borrado autom´ticamente. a 8 / 23
- 11. Algunas primitivas: Locks 1. Definimos un zNodo Zl que representa al lock. 2. Para adquirir el lock los procesos intentan crear Zl . create(Zl , data, ephemeral) 3. Si el proceso pudo crear el zNodo, entonces tiene el lock. 4. Si no pudo, espera a que sea eliminado y vuelve a intentar. exists(Zl , TRUE ) 9 / 23
- 12. Algunas primitivas: Locks 1. Definimos un zNodo Zl que representa al lock. 2. Para adquirir el lock los procesos intentan crear Zl . create(Zl , data, ephemeral) 3. Si el proceso pudo crear el zNodo, entonces tiene el lock. 4. Si no pudo, espera a que sea eliminado y vuelve a intentar. exists(Zl , TRUE ) Este lock tiene un problema... 9 / 23
- 13. Algunas primitivas: Locks 1. Definimos un zNodo Zl que representa al lock. 2. Para adquirir el lock los procesos intentan crear Zl . create(Zl , data, ephemeral) 3. Si el proceso pudo crear el zNodo, entonces tiene el lock. 4. Si no pudo, espera a que sea eliminado y vuelve a intentar. exists(Zl , TRUE ) Este lock tiene un problema... ¿Qu´ pasa si varios procesos esperan el lock? e 9 / 23
- 14. Algunas primitivas: Locks 2.0 1. Definimos un zNodo Zl que representa al lock. 2. Para adquirir el lock el proceso crea un nodo con Zl como padre. n = create(Zl + “/lock-”, data, ephemeral | sequential) 3. Obtiene la lista de hijos de Zl . getChildren(Zl , FALSE ) 4. Si n es el valor m´s chico, tiene el lock. a 5. Si no, define p = el valor el zNode que pidi´ el lock antes. o 6. Espera a que p termine de usar el lock. exists(p, TRUE ) 7. Repite desde 3 para asegurarse que tiene el lock. 10 / 23
- 15. La arquitectura de ZooKeeper ZooKeeper Service Write Request Response txn Request Processor Replicated Database Atomic Broadcast txn Read Request Figure 4: The components of theservicio Figura : Los componentes del ZooKeeper service. 11 / 23
- 16. ´ La implementacion: Request Processor Recibe los pedidos de actualizaci´n de los clientes. o Reenv´ los pedidos al l´ ıa ıder, o en caso de serlo, calcula el estado futuro del sistema para generar una transacci´n. o Las transacciones son idempotentes. Figura : L´ ıder y seguidores 12 / 23
- 17. ´ La implementacion: Atomic Broadcast Los servidores reciben las transacciones a trav´s de un e protocolo de broadcast at´mico. o El protocolo utiliza mayor´ simple para decidir si aplicar una ıa transacci´n. o Con 2n + 1 servidores se toleran n fallas. El protocolo garantiza el orden de entrega de las transacciones. 13 / 23
- 18. ´ La implementacion: Replicated Database Es una base de datos en memoria que contiene toda la estructura de datos. Se realizan fuzzy snapshots peri´dicos para acelerar la o restauraci´n en caso de ca´ del servidor. o ıda Ante una ca´ se reenv´ las transacciones perdidas. ıda ıan 14 / 23
- 19. Interacciones entre cliente y servidor Si un servidor procesa un pedido de actualizaci´n notifica a o todos los watches que est´n registrados para ese cambio. e Las escrituras son procesadas en orden y no permiten otras acciones concurrentes. Las lecturas se realizan localmente permitiendo alta performance al leer. Las respuestas est´n marcadas con el id de la ultima a ´ transacci´n vista. o Las sesiones tienen un timeout para monitorear a los clientes. 15 / 23
- 20. Pruebas y Resultados Se realizaron pruebas para medir el throughput y la latencia del sistema. Se utiliz´ un cl´ster de 50 servidores con las siguientes o u caracter´ısticas: Procesador Xeon dual-core 2.1GHz 4GB de RAM Gigabit ethernet Dos discos duros SATA 16 / 23
- 21. Pruebas y Resultados: Throughput Para testear el throughput realizaron un benchmark con el sistema saturado. Las pruebas consistieron en: 250 clientes simulados. 100 pedidos simult´neos por cliente, entre lecturas y escrituras a de 1K de datos. 2000 pedidos en proceso por servidor. 17 / 23
- 22. Pruebas y Resultados: Throughput Throughput of saturated system 90000 3 servers 80000 5 servers 7 servers 70000 9 servers 13 servers Operations per second 60000 50000 40000 30000 20000 10000 0 0 20 40 60 80 100 Percentage of read requests Figura : Throughput mientras var´ la relaci´n de lecturas/escrituras ıa o 18 / 23
- 23. Pruebas y Resultados: Throughput Para testear el throughput a medida que se suceden fallas realizaron el benchmark anterior, con un 30 % de escrituras. 19 / 23
- 24. Pruebas y Resultados: Throughput Time series with failures 70000 Throughput 60000 50000 Operations per second 40000 4c 6 30000 2 4b 1 4a 20000 10000 3 5 0 0 50 100 150 200 250 300 Seconds since start of series Figura : Throughput al ocurrir fallas 20 / 23
- 25. Pruebas y Resultados: Latencia Para calcular la latencia se realiz´ un benchmark que consisti´ en o o crear 50.000 zNodos de la siguiente manera: 1. Crear un zNodo con 1K de datos. 2. Hacer un delete asincr´nico. o 3. Volver a 1. 21 / 23
- 26. Pruebas y Resultados: Latencia Number of servers Workers 3 5 7 9 1 776 748 758 711 10 2074 1832 1572 1540 20 2740 2336 1934 1890 Figura : Pedidos procesados por segundo El throughput de un worker indica que la latencia promedio por pedido es de 1.2ms para 3 servidores y 1.4ms para 9 servidores. 22 / 23
- 27. En resumen... ZooKeeper Usa un enfoque wait-free para coordinar procesos en sistemas distribuidos. Provee una soluci´n general para distintas formas de o coordinaci´n. o Mediante el uso de las r´plicas locales y los watches permite e un alto throughput en situaciones donde predominan las lecturas. 23 / 23