|
このページは大阪弁化フィルタによって翻訳生成されたんですわ。 |
El trabajo extra introducido en el cliente debe ser m?imo, ya que es un coste a pagar incluso cuando no hay ca?as en el sistema.
La memoria extra utilizada debe ser m?ima, ya que la memoria reservada para obtener la fiabilidad puede ser utilizada por otros procesos o por el propio sistema operativo.
El tiempo de recuperaci? cuando se produce un fallo debe ser bajo.
Flouris y Markatos trabajaron sobre este problema en [1], y dise?ron e implementaron el Network Ram Disk (NRD) para Linux, el cual consegu? excelentes resultados en comparaci? con el rendimiento de los discos magn騁icos. El problema de la fiabilidad lo solucionan creando la t馗nica Adaptative Parity Caching. Sin embargo, esta t馗nica contiene ciertas desventajas que limitan sus posibles aplicaciones, como su uso en sistemas transaccionales, adem疽 de consumir recursos en el cliente.
Enhanced Network Ram Disk (ENRD) es un proyecto basado en NRD que investigaci?, ENRD busca la posibilidad de usar la memoria remota como una utilidad para los clusters Linux, donde su configuraci? sea r疳ida y sencilla y posibilite al administrador una herramienta m疽 para ofrecer al usuario de estos sistemas. Una de las aplicaciones del ENRD es como 疵ea swap donde puede ayudar a mejorar el tiempo de ejecuci? de sistemas limitados en memoria RAM. Es frecuente en grupos de investigaci? cient?icos ejecutar aplicaciones secuenciales creados por ellos mismos, no estando dispuestos a un coste extra de tiempo y esfuerzo en paralelizar la aplicaci?. En estos casos, ENRD ayudar? a mejorar el rendimiento de estas aplicaciones, que suelen necesitar enormes cantidades de memoria RAM, y por consiguiente hacen uso del 疵ea swap.
En sistemas transaccionales de gran volumen se usa Solid State Disks como almacenamiento, que es almacenamiento hardware basado en memoria RAM. Mientras que SSD es una soluci? profesional y m疽 cara, ENRD ofrece un uso m疽 din疥ico y la posibilidad de mejorar proporcionalmente a la velocidad cuando se hace uso intensivo de grandes cantidades de memoria RAM, lo que obliga a utilizar 疵ea swap degradando el rendimiento. En [2] y [3] se detallan dos prototipos dise?dos para Digital Unix. El primero explota la posibilidad de Network Ram en todos los niveles del sistema operativo (paginaci? de memoria virtual, ficheros mapeados en memoria y buffer del sistema de ficheros), consiguiendo la fiabilidad con escrituras as?cronas a disco. En el segundo, se usa Network Ram solo para paginaci?, estudiando diversas formas de conseguir la fiabilidad, como escrituras as?cronas a disco, mirroring y parity logging.
Los mismos autores de [3] son los creadores del NRD, donde utilizan la misma t馗nica para obtener la fiabilidad, pero modificada teniendo en aplicaci? en sistemas transaccionales, ya que no garantiza que los bloques escritos se encuentren en almacenamiento fiable en caso de fallo en el cliente. Adem疽, esta cache consume recursos en el cliente en la introducci?), que aunque despreciable en una simple operaci?, deja de serlo cuando se ejecuta millones de veces.
Para evitar estas limitaciones dise?mos e implementamos Enhanced Network Ram Disk(ENRD), consiguiendo incluso mejorar las prestaciones directamente, sino que lo hace con los servidores, salvo que falle alguno de estos. El funcionamiento del backup es as?crono respecto al cliente, y utiliza varias t馗nicas para realizar su tarea eficientemente, como unir bloques secuenciales en la misma llamada al sistema (en el siguiente apartado se explica con detalle su implementaci?). Para evitar que el cliente env? el mismo bloque dos veces usamos Multicasting[4]: cada nodo remoto pertenece a un grupo Multicast diferente, mientras el nodo backup pertenece a todos. De
En el dise? del NRD el sistema se compon? de un nodo cliente y varios nodos remotos (servidores). En el nodo cliente se a?d? un m?ulo al kernel del sistema para poder acceder a un dispositivo de bloque virtual por medio de un driver, el cual se sincronizaba con un daemon(duende) a nivel de usuario. El daemon es el que se encarga de comunicarse con los servidores para la escritura o lectura de bloques. Los servidores escuchaban en dos puertos, uno de lectura y otro de escritura, y su funci? era copiar los bloques recibidos a memoria en las operaciones de escritura, y por otra parte enviar los bloques pedidos en las operaciones de lectura. Como ya hemos env? a los diferentes grupos Multicast y sustituir a uno de los servidores en caso de ca?a. El nuevo dise? para conseguir la fiabilidad sit? la complejidad del c?igo en el nodo backup, aunque en menor medida que las que pod?n tener el daemon del cliente y los servidores en el NRD cuando se implementaban con la t馗nica de paridad.
El funcionamiento del daemon en el cliente y de los servidores es sencilla y f當il de implementar, siendo equivalente al NRD original en su versi? UNRELIABLE, la cual funcionaba sin garantizar la fiabilidad. Se han a?dido las funcionalidades necesarias de recuperaci? en caso de que el nodo cliente detecte el fallo de un servidor, que funciona mediante un timeout y el env? de un paquete de RECOVERY del cliente al backup. Por otra parte, al usar Multicast nos obliga a usar el protocolo UDP, que implica que no hay garant?s en el env? y recepci? de los paquetes. Por lo tanto hay que implementar un control de flujo a nivel de aplicaci? (m疽 adelante explicaremos su implementaci?). Cabe se?lar que existen trabajos sobre Multicast con fiabilidad [5] con el mismo rendimiento que sobre UDP y que podr?n ser aplicados con ENRD en el futuro.
A continuaci? nos centraremos en el funcionamiento del nodo backup, y de las t馗nicas utilizadas en su dise?, y c?o afectan en 駘 varias limitaciones que encontramos en las pruebas.
A?dir un nuevo componente cuya funcionalidad sea escribir los bloques de escritura a disco magn騁ico es justamente lo que se trata de evitar con el NRD y ENRD, ya que como dijimos anteriormente, la latencia del sistema. Este m騁odo es utilizado en [2] pero no de una forma adecuada, ya que son los servidores los que realizan las escrituras a disco. Esto puede ocasionar la p駻dida de datos, ya que un fallo puede ocurrir cuando el bloque haya sido copiado a memoria pero a? no haya sido escrito a disco. Adem疽, en una situaci? de escritura de gran cantidad de bloques, el sistema se ver? colapsado, ocasionando que el funcionamiento deje de ser as?crono. En ENRD al utilizar un nodo de backup nos aseguramos que en caso de ca?a de un servidor, exista una copia de sus bloques en el backup, lo que garantiza la fiabilidad. Para solucionar el problema de escritura de una gran cantidad de bloques en un corto espacio de tiempo, debemos recordar que para escrituras, mientras un servidor debe copiar el contenido del bloque recibido a memoria, el backup lo debe escribir a disco. Obviamente el backup no lo puede realizar a la misma velocidad (esta es la raz? de ser del ENRD) por lo que debe usar varias t馗nicas que le permitan realizar esta tarea:
Unir bloques secuenciales: evitando de esta manera realizar tantas llamadas al sistema como bloques recibidos.
Repartir las funciones de recepci? de bloques y escritura a disco.
La primera t馗nica viene determinada por una caracter?tica de las operaciones de escritura y que es aprovechada por los discos para mejorar su rendimiento: las escrituras de bloques secuenciales. Si unimos varios bloques cuya posici? es consecutiva en el disco, en la misma operaci?, evitamos que la cabeza del disco tenga que desplazarse y ahorramos la latencia que se producir?. dem疽, evitamos realizar una llamada al sistema por cada bloque recibido. de los datos de los bloques, y el tercer par疥etro es el numero de bloques a escribir(realmente es el n?ero de bytes pero usamos el n?ero de bloques para facilitar la explicaci?). De esta manera el sistema se evita realizar 5 llamadas al sistema, siendo adem疽 seguro que los bloques se escribir疣 consecutivamente a disco si usamos un sistema de ficheros ext3 o XFS, lo que aumenta el rendimiento total del backup al no tener que desplazarse la cabeza del disco.
La segunda t馗nica viene dada por el problema de desbordamiento del buffer de comunicaciones que puede ocurrir en determinadas circunstancias. Para ello tenemos que conocer como funcionan las tarjetas de red y la pila de comunicaciones del sistema [6] y [7]. Cuando la tarjeta de red recibe un paquete, lo escribe a unos buffers en memoria aprovechando los canales de DMA (acceso directo a memoria). El sistema operativo se encarga de procesar estos paquetes a trav駸 de la pila de comunicaciones, copiando finalmente su contenido a un buffer a nivel de proceso, que es creado cuando se realiza la llamada al sistema para la creaci? de sockets. Aunque el tama? de este buffer es configurable y puede ser ampliado, el peligro de desbordamiento sigue existiendo, ya que si llegan paquetes y el buffer los nuevos bloques desde el buffer a nivel socket al buffer a nivel de aplicaci?, y buscar la posibilidad de unir este nuevo bloque con otros que ya estuviesen en el buffer. Mientras, el escritor se sincroniza con que finalize la operaci? de escritura, pueden llegar bloques al sistema, y pueden ser tratados por el escuchador. Si s?o existiera un hilo, ser? m疽 f當il que hubiera problemas de desbordamiento del buffer de socket.
Hemos estado hablando del dise? del backup, y de las t馗nicas usadas para que pueda realizar su tarea sin convertirse en un cuello de botella . Sin embargo, a la hora de la implementaci? surgieron varias limitaciones que afectaron al dise? descrito.
La primera de ellas es importante aunque no obliga a redise?r el sistema. Surge por la tecnolog? de interconexi? usada. En las pruebas realizadas usamos un switch Ovislink Fast Ethernet sin soporte real de Multicasting y un switch 3COM que si lo soportaba, ambos de 24 puertos. Para nuestra sorpresa, el 3COM era sumamente lento cuando rendimientos para un n?ero de 7 nodos. A pesar de usar un dise? basado en Multicast en tecnolog?s sin soporte para ello los resultados son satisfactorios, aunque habr? que estudiar el comportamiento con un mayor n?ero de nodos, donde la pol?ica de reenv? a cada puerto pueda soponer una sobrecarga evidente.
Una segunda limitaci? es el comportamiento del switch para escrituras de un gran n?ero de bloques consecutivamente. Si el cliente env? un gran n?ero de peticiones de escritura seguidas, el switch se ve incapaz de manejarlas, lo que origina la p駻dida de paquetes dentro del switch. Esto obliga a realizar un control de flujo a nivel de aplicaci?, cuya implementaci? era obligado debido al protocolo lo que podr? ser suficiente para uso en redes locales (aunque pendiente para un trabajo futuro). La implementaci? del control de flujo se limita a una labor de sincronismo cada 100 bloques enviados (50 paquetes), consistente en el env? de un paquete SYNC del cliente a cada nodo y la contestaci? de cada nodo al cliente. Actualmente el paquete de contestaci? es siempre el mismo, un paquete de OK. Para un control de flujo m疽 eficiente se usar? una peque? cache en el cliente (unos 100Kbytes), donde el paquete de contestaci? fuera m疽 buffer es elevado, el escuchador tarda en realizar esta tarea, lo que origina que nuevos bloques lleguen al buffer a nivel socket con el peligro de desbordamiento. Para evitar la p駻dida de bloques introducimos un paquete de sincronismo con el backup junto con los paquetes de sincronismo que se env?n a los servidores, lo que conlleva a que el funcionamiento del backup respecto al cliente no sea realmente as?crono, ya que en caso de escritura de un gran n?ero de bloques el paquete de OK mandado desde el backup al cliente sufre un peque? retraso, introduciendo una peque? sobrecarga en los resultados. Sin embargo, esta sobrecarga es lo suficientemente peque? como para conseguir una eficiecia mejor que el NRD original como veremos en las gr畴icas de resultados de las pruebas. El coste de b?queda y de inserci? en el buffer puede ser mejorado sustancialmente usando 疵boles binarios como estructura de datos cuando el n?ero de bloques alcanze un determinado tama?, al igual que se usa en el kernel de Linux para recorrer el array de p疊inas. backup. De esta manera veremos cual es la sobercarga que introduce el sincronismo del backup explicado en el apartado anterior. Veremos tambi駭 cual es el efecto de las t馗nicas empleadas en el backup que permite al sistema el ahorro de un gran n?ero de llamadas al sistema.
fichero de fs tama? en bloques de rs bytes un total de wn veces.
Se definieron distintas pruebas con varios tama?s de ficheros y varios tama?s de registro de escritura, lanzando 1, 5, 10 y 20 threads. Cada uno de estos threads escrib? 10000 veces cada fichero. Los ficheros son creados con el flag O_SYNC, lo que obliga al sistema a escribir a disco antes de finalizar la llamada de escritura (por eficiencia, sin este flag el sistema escribe en el Buffer Cache del sistema y posteriormente lo hace a disco). De esta manera es como
1 thread, escribiendo ficheros de diferentes tama?s en bloques de 1024 bytes 10000 veces. Los resultados son los tiempos medios de escritura por fichero en milisegundos.
Tama? fichero Disco NRD ENRD(backup) ENRD
1024 21 0 0 0 2048 41 1 0 0 4096 83 2 0 0 8192 164 5 1 1 16384 328 11 3 3 32768 648 26 8 8 65536 56 18 18
ﾚnicamente en esta tabla mostramos el comportamiento del disco, que ya es suficientemente significativa. Vemos como el backup no produce ninguna sobrecarga con tan poca carga.
2 thread, escribiendo ficheros de diferentes tama?s en bloques de 1024 bytes 10000 veces. Los resultados son los tiempos medios de escritura por fichero en milisegundos.
Tama? fichero NRD ENRD(backup) ENRD
1024 1 0 0 2048 2 0 0 4096 4 1 1 8192 8 4 2 16384 18 6 6 32768 45 16 15 65536 95 35 33
La sobrecarga del backup es peque?, pero ya afecta al rendimiento del sistema.
5 thread, escribiendo ficheros de diferentes tama?s en bloques de 1024 bytes 10000 veces. Los resultados son los tiempos medios de escritura por fichero en milisegundos.
Tama? fichero NRD ENRD(backup) ENRD
1024 3 1 1 2048 5 2 2 4096 9 4 3 8192 19 7 6 16384 43 18 14 32768 108 39 35 65536 238 82 77
10 thread, escribiendo ficheros de diferentes tama?s en bloques de 1024 bytes 10000 veces. Los resultados son los tiempos medios de escritura por fichero en milisegundos.
Tama? fichero NRD ENRD(backup) ENRD
1024 8 7 7 2048 14 9 8 4096 22 11 10 8192 37 17 15 16384 78 45 29 32768 186 78 67 65536 656 162 146
20 thread, escribiendo ficheros de diferentes tama?s en bloques de 1024 bytes 10000 veces. Los resultados son los tiempos medios de escritura por fichero en milisegundos.
Tama? fichero NRD ENRD(backup) ENRD
2048 50 40 38 4096 68 45 43 8192 103 54 52 16384 249 145 77 32768 790 211 147 65536 1780 502 272
Durante las pruebas, el porcentaje de buffer de aplicaci? en el
La limitaci? de mejora en el rendimiento de los discos magn騁icos debido a su naturaleza mec疣ica los convierten en el principal cuello de botella de los actuales sistemas, y considerando que las velocidades de los procesadores y de las comunicaciones en las redes de 疵ea local continuar疣 aumentando en el futuro, las limitaciones de los disco magn騁icos se ver疣 acentuadas los pr?imos a?s. Utilizando parte de las causas de este problema, los procesadores y las comunicaciones, podemos aumentar el rendimiento de las aplicaciones que hacen uso intensivo de la entrada/salida a disco, usando para ello la memoria de nodos remotos. De esta manera aprovechamos los ciclos de computaci? de los procesadores que quedaban sin utilizarse debido a la diferencia de rendimiento entre los distintos componentes del sistema.
En NRD se lograba alcanzar los objetivos descritos, pero con ciertas limitaciones que lo hac?n inapropiado para sistemas transaccionales. Adem疽 utilizaba demasiados recursos del cliente que pod?n ser empleados para otros prop?itos.
Con ENRD evitamos estas limitaciones al mismo tiempo que conseguimos un mejor rendimiento incluso respecto al NRD sin fiabilidad. Para esto nos basamos en un nodo backup trabajando as?cronamente respecto al cliente, el cual guarda todos los bloques de escritura a disco magn騁ico, utilizando varias t駭icas de programaci? para realizar su tarea eficientemente.
En un trabajo futuro se puede mejorar el rendimiento del sistema ENRD para conseguir una verdadera asincron? entre el cliente y el backup. Su pricipal limitaci? es la forma de recorrer la lista de bloques en la cache del backup, lo que en estos momentos se realiza de una manera secuencial. Utilizar otras estructuras de datos m疽 apropiadas, como 疵boles binarios balanceados, cuando el tama? de una lista es relativamente grande, podr? mejorar el rendimiento al disminuir la sobrecarga del backup respecto al cliente. Otro punto de mejora es el control de flujo, el cual no es dif?il de implementar y se requerir? para poder usar ENRD en sistemas comerciales. Como hemos comentado, la posibilidad de usar una versi? fiable de Multicast evitar? dicha implementaci? a nivel de aplicaci?. Modificar el dise? del ENRD para que sea el propio driver en vez del daemon el que se comunique con los servidores remotos ser? interesante y mejorar? el rendimiento (esta idea se ha utilizado en el kernel httpd server).
Por ?timo, un estudio de las posibilidades de ENRD con tecnolog?s de red m疽 avanzadas ser? conveniente, o simplemente con librer?s de comunicaciones que eviten la sobrecarga de usar la pila TCP/IP como GAMMA[9].
Michael D. Flouris y Evangelos P. Markatos. The Network Ram Disk: using remote memory on heterogeneous NOW's. Cluster Computing: The Journal on Networks, Software and Applications, 2 (4), pp. 281-293,1999, Baltzer Science Publishers.
M.J. Feeley, W.E. Morgan, F.H. Pighin, A.R. Karlin, H.M. Levy y C.A. Thekkath. Implementing Global Memory Management in a Workstation Cluster. En Proceedings of the 15th Symposium on Operating Systems Principles, pp. 201-212, diciembre 1995
E.P. Markatos y G. Dramitinos. Implementation of a Reliable Remote Memory Pager. En Proceedings of de 1996 Usenix Technical Conference, pp. 177-190, enero 1996.
R. Braudes y S. Zabele. Requeriments for Multicast Protocols, FRC 1458, mayo 1993.
Alex Koifman y Stephen Zabele. RAMP: A Reliable Adaptative Multicast Protocol. En Proceedings of IEEE INFOCOM, pp. 1442-1451, marzo 1996.
Glenn Herrin. Linux IP Networking: A Guide to the Implementation and Modification of the Linux Protocol Stack. http://kernelnewbies.org/documents/ipnetworking/linuxipnetworking.html
http://www.3com.com 3c90xc NICs Technical Reference (3COM). Part Number: 89-0931-000. Publicado en septiembre de 1999.
http://www.gnu.org/directory/Software_Libraries/C_libraries/libavl.html