Se otorga permiso para copiar, distribuir y/o modificar este documento bajo los t�rminos de la Licencia de Documentaci�n Libre GNU, Versi�n 1.1 o cualquier otra versi�n posterior publicada por la Free Software Foundation, no habiendo Secciones Invariantes, ni Textos de Portada ni Textos de Contra Portada. La licencia completa se puede consultar en: http://www.gnu.org/copyleft/fdl.html
Resumen
La capacidad de los procesadores se dobla cada 18 meses, y las tecnolog�as en redes de �rea local est�n acerc�ndose al rendimiento reservado a sistemas multiprocesadores. Los discos magn�ticos aumentan su capacidad de almacenamiento a un ritmo similar, sin embargo, la latencia de acceso a los mismos est� limitada por la naturaleza mec�nica de estos dispositivos. Esto convierte a los discos magn�ticos en el pricipal cuello de botella de los actuales sistemas, siendo un problema que se agudizar� en el futuro. Gracias a los avances en los procesadores y sobre todo en las comunicaciones en redes de �rea local, es posible usar la memoria de nodos remotos como sistema de almacenamiento. La principal desventaja de este tipo de sistemas es su fiabilidad, ya que la probabilidad de fallo aumenta proporcionalmente con el n�mero de nodos, y que el fallo de un nodo afecta a todo el sistema. En este trabajo exponemos un nuevo m�todo para obtener la fiabilidad. Hemos basado nuestro proyecto en un trabajo anterior, consiguiendo mejorar sus prestaciones adem�s de eliminar su principal limitaci�n: su uso en sistemas transaccionales.
Tabla de contenidos
La capacidad de los procesadores se dobla cada 18 meses (Ley de Moore), y las tecnolog�as en redes de �rea local est�n alcanzando cotas que hasta hace bien poco eran s�lo posibles es sistemas multiprocesadores. Los discos magn�ticos aumentan su capacidad de almacenamiento a un ritmo similar, sin embargo, la latencia de acceso a los mismos est� limitada por la naturaleza mec�nica de estos dispositivos. Esta limitaci�n convierte a los discos en el principal cuello de botella de los sistemas actuales, siendo este un problema que se agudizar� en el futuro.
Gracias a los avances de los procesadores y de las comunicaciones en redes de �rea local, es factible desde un punto de vista de rendimiento, usar la memoria de nodos remotos como un disco virtual mucho m�s r�pido que los discos magn�ticos. Sin embargo, desde un punto de vista de la fiabilidad del sistema, el principal problema de utilizar la memoria de nodos remotos es que la ca�da de un nodo afecta a todo el conjunto, aumentando la probabilidad de fallo proporcionalmente con el n�mero de nodos utilizados. Para obtener la fiabilidad en este tipo de sistemas hay que hacer tres consideraciones:
El trabajo extra introducido en el cliente debe ser m�nimo, ya que es un coste a pagar incluso cuando no hay ca�das en el sistema.
La memoria extra utilizada debe ser m�nima, 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�n cuando se produce un fallo debe ser bajo.
Flouris y Markatos trabajaron sobre este problema en [1], y dise�aron e implementaron el Network Ram Disk (NRD) para Linux, el cual consegu�a excelentes resultados en comparaci�n con el rendimiento de los discos magn�ticos. El problema de la fiabilidad lo solucionan creando la t�cnica Adaptative Parity Caching. Sin embargo, esta t�cnica contiene ciertas desventajas que limitan sus posibles aplicaciones, como su uso en sistemas transaccionales, adem�s de consumir recursos en el cliente.
Enhanced Network Ram Disk (ENRD) es un proyecto basado en NRD que soluciona los problemas de �ste utilizando otro dise�o para obtener la fiabilidad, consiguiendo mejorar el rendimiento y disminuyendo la complejidad en el c�digo. ENRD est� basado en la idea de utilizar un nodo remoto como almacenamiento de backup: dicho nodo recibir� todos los bloques de escritura y los guardar� a disco magn�tico, siendo su funcionamiento as�ncrono respecto al nodo cliente. Mientras que el trabajo original de Flouris y Markatos era un proyecto de investigaci�n, ENRD busca la posibilidad de usar la memoria remota como una utilidad para los clusters Linux, donde su configuraci�n sea r�pida y sencilla y posibilite al administrador una herramienta m�s para ofrecer al usuario de estos sistemas. Una de las aplicaciones del ENRD es como �rea swap donde puede ayudar a mejorar el tiempo de ejecuci�n de sistemas limitados en memoria RAM. Es frecuente en grupos de investigaci�n cient�ficos ejecutar aplicaciones secuenciales creados por ellos mismos, no estando dispuestos a un coste extra de tiempo y esfuerzo en paralelizar la aplicaci�n. En estos casos, ENRD ayudar�a a mejorar el rendimiento de estas aplicaciones, que suelen necesitar enormes cantidades de memoria RAM, y por consiguiente hacen uso del �rea 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�n profesional y m�s cara, ENRD ofrece un uso m�s din�mico y la posibilidad de mejorar proporcionalmente a la velocidad de CPU's y tecnolog�as de comunicaciones.
La idea de usar la memoria de nodos remotos no es nueva, habi�ndose completado en el pasado varios proyectos donde la implementaci�n de prototipos demostr� las posibilidades que aparecen en estos sistemas. En especial se estudi� la forma de mejorar el rendimiento cuando se hace uso intensivo de grandes cantidades de memoria RAM, lo que obliga a utilizar �rea swap degradando el rendimiento. En [2] y [3] se detallan dos prototipos dise�ados para Digital Unix. El primero explota la posibilidad de Network Ram en todos los niveles del sistema operativo (paginaci�n de memoria virtual, ficheros mapeados en memoria y buffer del sistema de ficheros), consiguiendo la fiabilidad con escrituras as�ncronas a disco. En el segundo, se usa Network Ram solo para paginaci�n, estudiando diversas formas de conseguir la fiabilidad, como escrituras as�ncronas a disco, mirroring y parity logging.
Los mismos autores de [3] son los creadores del NRD, donde utilizan la misma t�cnica para obtener la fiabilidad, pero modificada teniendo en cuenta las distintas caracter�sticas entre el acceso a un �rea swap y a un sistema de ficheros. Esta t�cnica denominada Adaptative Parity Caching, consigue obtener un mayor rendimiento en comparaci�n con el uso de discos magn�ticos. Sin embargo, el uso de una cach� en el cliente limita su aplicaci�n en sistemas transaccionales, ya que no garantiza que los bloques escritos se encuentren en almacenamiento fiable en caso de fallo en el cliente. Adem�s, esta cache consume recursos en el cliente (segunda consideraci�n en la introducci�n) que podr�an ser usados por otros procesos o por el sistema operativo: para un Network Ram Disk de 16Gbytes, la cach� usar�a 80Mbytes. Finalmente, el c�lculo de la paridad de bloques lo debe realizar el cliente (primera consideraci�n en la introducci�n), que aunque despreciable en una simple operaci�n, deja de serlo cuando se ejecuta millones de veces.
Para evitar estas limitaciones dise�amos e implementamos Enhanced Network Ram Disk(ENRD), consiguiendo incluso mejorar las prestaciones del NRD original, adem�s de liberar al c�digo de la complejidad de implementar Adaptative Parity Caching. Para ello, evitamos el uso de memoria en el cliente para obtener la fiabilidad y el coste extra en el calculo de la paridad. En el nuevo dise�o, el cliente enviar� los bloques de escritura al nodo remoto y a un nuevo nodo denominado backup, mientras que las peticiones de bloques de lectura las enviar� �nicamente al nodo remoto. El cliente no trabaja con el backup directamente, sino que lo hace con los servidores, salvo que falle alguno de estos. El funcionamiento del backup es as�ncrono respecto al cliente, y utiliza varias t�cnicas 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�n). Para evitar que el cliente env�e 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 esta manera el env�o de un bloque a una direcci�n Multicast ser� recibido por el nodo remoto y por el nodo backup, liberando al cliente de esta tarea y dej�ndosela a las tecnolog�as de interconexi�n de red. En el caso de fallo en un nodo remoto, el cliente enviar� un paquete de RECOVERY al nodo backup, el cual copiar� de disco a memoria los bloques pertenecientes al nodo fallido y continuar� su ejecuci�n realizando las funciones del servidor.
En el dise�o del NRD el sistema se compon�a de un nodo cliente y varios nodos remotos (servidores). En el nodo cliente se a�ad�a un m�dulo 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�n 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 comentado, la implementaci�n de Adaptative Parity Caching supon�a que el daemon consumiera recursos del cliente como la memoria usada para la cach�, o tiempo de procesador para calcular la paridad de bloques, a�adiendo adem�s cierta complejidad al c�digo.
El dise�o de ENRD est� basado en el NRD, pero el cliente y los servidores se han liberado de una cierta complejidad al no usar Adaptative Parity Caching, y han sido modificados convenientemente para usar Multicasting. El driver ha sido modificado para evitar posibles condiciones de carrera, utilizando sem�foros en vez de las funciones sleep and wake_up para la sincronizaci�n entre el driver y el daemon. Se a�ade un nuevo componente al sistema: el nodo backup. Su funci�n ser� recibir todos los paquetes de escritura que el cliente env�e a los diferentes grupos Multicast y sustituir a uno de los servidores en caso de ca�da. El nuevo dise�o para conseguir la fiabilidad sit�a la complejidad del c�digo en el nodo backup, aunque en menor medida que las que pod�an tener el daemon del cliente y los servidores en el NRD cuando se implementaban con la t�cnica de paridad.
El funcionamiento del daemon en el cliente y de los servidores es sencilla y f�cil de implementar, siendo equivalente al NRD original en su versi�n UNRELIABLE, la cual funcionaba sin garantizar la fiabilidad. Se han a�adido las funcionalidades necesarias de recuperaci�n en caso de que el nodo cliente detecte el fallo de un servidor, que funciona mediante un timeout y el env�o 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�as en el env�o y recepci�n de los paquetes. Por lo tanto hay que implementar un control de flujo a nivel de aplicaci�n (m�s adelante explicaremos su implementaci�n). Cabe se�alar que existen trabajos sobre Multicast con fiabilidad [5] con el mismo rendimiento que sobre UDP y que podr�an ser aplicados con ENRD en el futuro.
A continuaci�n nos centraremos en el funcionamiento del nodo backup, y de las t�cnicas utilizadas en su dise�o, y c�mo afectan en �l varias limitaciones que encontramos en las pruebas.
A�adir un nuevo componente cuya funcionalidad sea escribir los bloques de escritura a disco magn�tico es justamente lo que se trata de evitar con el NRD y ENRD, ya que como dijimos anteriormente, la latencia del disco magn�tico se convierte en el principal escollo a resolver en los actuales y futuros sistemas. Por lo tanto puede parecer una contradicci�n usarlo dentro de la soluci�n. La clave est� en que estas escrituras se realizan as�ncronamente respecto al funcionamiento del sistema. Este m�todo 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�rdida de datos, ya que un fallo puede ocurrir cuando el bloque haya sido copiado a memoria pero a�n no haya sido escrito a disco. Adem�s, en una situaci�n de escritura de gran cantidad de bloques, el sistema se ver�a colapsado, ocasionando que el funcionamiento deje de ser as�ncrono. En ENRD al utilizar un nodo de backup nos aseguramos que en caso de ca�da 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�n de ser del ENRD) por lo que debe usar varias t�cnicas 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�n de bloques y escritura a disco.
La primera t�cnica viene determinada por una caracter�stica 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�n es consecutiva en el disco, en la misma operaci�n, evitamos que la cabeza del disco tenga que desplazarse y ahorramos la latencia que se producir�a. dem�s, evitamos realizar una llamada al sistema por cada bloque recibido. Para conseguir esto usaremos una cache a nivel de aplicaci�n donde los bloques recibidos ser�n copiados y donde se intentar� unirlos si fuera posible: deben pertenecer al mismo servidor y poseer n�meros de bloques consecutivos. Los bloques ser�n escritos a disco cuando el n�mero de bloques en la cach� del backup lleguen a una cierta cantidad predeterminada. Como ejemplo vamos a tomar una cache de 100 bloques, siendo 10 el l�mite de bloques en la cache para volcar a disco. Llegan 12 bloques al backup: a6-a7-b3-b8-b9-a1-a2-a3-c6-c7-b1-b2. La letra indica el servidor al que va destinado el bloque y el n�mero es el n�mero de bloque dentro de ese servidor. Cuando llegue el d�cimo bloque c7, los bloques que est�n es ese momento en la cach� ser�n escritos a disco con 5 llamadas al sistema: write(a,-,2) write(b,-,1) write(b,-,2) write(a,-,3) write(c,-,2), donde el primer par�metro es el fichero asociado con el servidor, el segundo en una variable que usar� el backup en la implementaci�n y donde se copiar� el contenido de los datos de los bloques, y el tercer par�metro es el numero de bloques a escribir(realmente es el n�mero de bytes pero usamos el n�mero de bloques para facilitar la explicaci�n). De esta manera el sistema se evita realizar 5 llamadas al sistema, siendo adem�s seguro que los bloques se escribir�n 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�cnica 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�s 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�n de sockets. Aunque el tama�o de este buffer es configurable y puede ser ampliado, el peligro de desbordamiento sigue existiendo, ya que si llegan paquetes y el buffer est� lleno, el sistema los descarta (en este caso el protocolo de transporte de red no tiene nada que hacer, ya que para �l los paquetes han llegado sin problemas). Por lo tanto, en caso de que el proceso est� ocupado escribiendo bloques a disco, una llegada masiva de nuevos bloques podr�a originar el desbordamiento del buffer del socket, perdiendo de esta manera informaci�n. La soluci�n est� en el famoso �divide y vencer�s?: usaremos hilos (POSIX threads) para dividir la tarea entre un thread escuchador y un thread escritor. La tarea del escuchador es copiar los nuevos bloques desde el buffer a nivel socket al buffer a nivel de aplicaci�n, y buscar la posibilidad de unir este nuevo bloque con otros que ya estuviesen en el buffer. Mientras, el escritor se sincroniza con el escuchador para escribir los bloques del buffer de aplicaci�n a disco con las m�nimas llamadas al sistema, gracias a la labor de uni�n de bloques del escuchador. A�n en el caso de sistemas monoprocesadores este dise�o es eficaz, ya que mientras que el proceso escritor est� esperando que finalize la operaci�n de escritura, pueden llegar bloques al sistema, y pueden ser tratados por el escuchador. Si s�lo existiera un hilo, ser�a m�s f�cil que hubiera problemas de desbordamiento del buffer de socket.
Hemos estado hablando del dise�o del backup, y de las t�cnicas usadas para que pueda realizar su tarea sin convertirse en un cuello de botella . Sin embargo, a la hora de la implementaci�n surgieron varias limitaciones que afectaron al dise�o descrito.
La primera de ellas es importante aunque no obliga a redise�ar el sistema. Surge por la tecnolog�a de interconexi�n 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 ten�a activada la funcionalidad de Multicast, lo que degradaba el funcionamiento del sistema hasta el punto de ser peor que cuando usamos el disco magn�tico. El soporte Multicast se basa en almacenar en una tablas internas qu� puertos del switch han enviado paquetes de pertenencia a alguna direcci�n de Multicast. As�, cuando llegue un paquete con este protocolo, el switch usa estas tablas para reenviar el paquete s�lo a los puertos adecuados, en vez de enviarlo a cada puerto, que es lo que realiza cuando no tiene dicho soporte. Parece ser, por lo menos en nuestras pruebas, que es m�s eficiente para el switch enviar el paquete al buffer de salida de cada puerto que leer las tablas y enviarlo s�lo a los miembros del grupo dado. As�, tanto el 3COM sin funcionalidad Multicast como el Ovislink consegu�an excelentes rendimientos para un n�mero de 7 nodos. A pesar de usar un dise�o basado en Multicast en tecnolog�as sin soporte para ello los resultados son satisfactorios, aunque habr�a que estudiar el comportamiento con un mayor n�mero de nodos, donde la pol�tica de reenv�o a cada puerto pueda soponer una sobrecarga evidente.
Una segunda limitaci�n es el comportamiento del switch para escrituras de un gran n�mero de bloques consecutivamente. Si el cliente env�a un gran n�mero de peticiones de escritura seguidas, el switch se ve incapaz de manejarlas, lo que origina la p�rdida de paquetes dentro del switch. Esto obliga a realizar un control de flujo a nivel de aplicaci�n, cuya implementaci�n era obligado debido al protocolo UDP. El control de flujo implementado esta pensado para evitar la limitaci�n del switch en cuanto al n�mero de paquetes en fila o consecutivos y no como un completo y eficiente control de flujo. Durante los tests efectuados no se perdi� ning�n paquete, por lo que podr�a ser suficiente para uso en redes locales (aunque pendiente para un trabajo futuro). La implementaci�n del control de flujo se limita a una labor de sincronismo cada 100 bloques enviados (50 paquetes), consistente en el env�o de un paquete SYNC del cliente a cada nodo y la contestaci�n de cada nodo al cliente. Actualmente el paquete de contestaci�n es siempre el mismo, un paquete de OK. Para un control de flujo m�s eficiente se usar�a una peque�a cache en el cliente (unos 100Kbytes), donde el paquete de contestaci�n fuera m�s complejo, indicando si alg�n bloque no se recibi� y cu�l o cu�les de ellos fallaron.
Por �ltimo, las t�cnicas utilizadas en el dise�o del backup no son suficientes, perdiendo el backup bloques en situaciones de escrituras masivas. El problema no est� en el dise�o, sino en la implementaci�n. El thread escuchador, cada vez que llega un nuevo paquete debe buscar que ese bloque no se encuentre ya en el buffer, recorriendo la lista de bloques en el buffer de una forma secuencial. Cuando el tama�o de una lista es mayor que unos pocos elementos, est� demostrado que existen otras estructuras de datos m�s adecuadas, como �rboles binarios balanceados AVL[8].Por este motivo, cuando el n�mero de bloques en el 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�rdida de bloques introducimos un paquete de sincronismo con el backup junto con los paquetes de sincronismo que se env�an a los servidores, lo que conlleva a que el funcionamiento del backup respecto al cliente no sea realmente as�ncrono, ya que en caso de escritura de un gran n�mero de bloques el paquete de OK mandado desde el backup al cliente sufre un peque�o retraso, introduciendo una peque�a sobrecarga en los resultados. Sin embargo, esta sobrecarga es lo suficientemente peque�a como para conseguir una eficiecia mejor que el NRD original como veremos en las gr�ficas de resultados de las pruebas. El coste de b�squeda y de inserci�n en el buffer puede ser mejorado sustancialmente usando �rboles binarios como estructura de datos cuando el n�mero de bloques alcanze un determinado tama�o, al igual que se usa en el kernel de Linux para recorrer el array de p�ginas.
ENRD est� basado en un trabajo anterior, en el cual se realizaron varias pruebas para comparar su rendimiento respecto al disco. En nuestro trabajo conseguimos mejorar las prestaciones del NRD, haciendo su uso posible en sistemas transaccionales. Por lo tanto, nuestras pruebas est�n orientadas a comparar el ENRD y el NRD, que obviamente demostrar� que ENRD es mucho m�s eficiente que el disco. Utilizamos la versi�n m�s r�pida del NRD en la cual no existe fiabilidad, y se comparar� al ENRD con fiabilidad activada (el nodo backup funcionando) y al ENRD sin backup. De esta manera veremos cual es la sobercarga que introduce el sincronismo del backup explicado en el apartado anterior. Veremos tambi�n cual es el efecto de las t�cnicas empleadas en el backup que permite al sistema el ahorro de un gran n�mero de llamadas al sistema.
Para la realizaci�n de las pruebas se utiliz� un programa llamado lutherbench, creado por nosotros. Dicho programa utiliza varios par�metros: n�mero de threads n, tama�o de fichero fs, tama�o de registro rs y n�mero de escrituras wn. Cada thread escribir� un fichero de fs tama�o en bloques de rs bytes un total de wn veces.
Se definieron distintas pruebas con varios tama�os de ficheros y varios tama�os de registro de escritura, lanzando 1, 5, 10 y 20 threads. Cada uno de estos threads escrib�a 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 funcionan los sistemas transaccionales.
Se utilizaron 7 nodos biprocesadores Pentium III 1Ghz, 512Mbytes de RAM, tarjetas Intel Ethernet Pro 100, Discos IDE y switch Ovislink 124TH+. En cada uno de los 5 nodos servidores se us� 200Mbytes como parte del ENRD, y se us� el mismo tama�o en el buffer del nodo backup.
1 thread, escribiendo ficheros de diferentes tama�os en bloques de 1024 bytes 10000 veces. Los resultados son los tiempos medios de escritura por fichero en milisegundos.
Tama�o 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�os en bloques de 1024 bytes 10000 veces. Los resultados son los tiempos medios de escritura por fichero en milisegundos.
Tama�o 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�o, pero ya afecta al rendimiento del sistema.
5 thread, escribiendo ficheros de diferentes tama�os en bloques de 1024 bytes 10000 veces. Los resultados son los tiempos medios de escritura por fichero en milisegundos.
Tama�o 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�os en bloques de 1024 bytes 10000 veces. Los resultados son los tiempos medios de escritura por fichero en milisegundos.
Tama�o 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�os en bloques de 1024 bytes 10000 veces. Los resultados son los tiempos medios de escritura por fichero en milisegundos.
Tama�o 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�n en el backup utilizado no super� nunca el 20% , por lo que se puede ajustar el tama�o del buffer en lugar de usar el mismo tama�o de memoria que en los servidores.
En http://torus.gap.upv.es:8080/enrd/english/results.html se pueden ver tablas para otros tama�os de registro de escritura, as� como el resultado de utilizar ENRD con la base de datos Postgresql, simulando transacciones.
La limitaci�n de mejora en el rendimiento de los discos magn�ticos debido a su naturaleza mec�nica 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 �rea local continuar�n aumentando en el futuro, las limitaciones de los disco magn�ticos se ver�n acentuadas los pr�ximos a�os. 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�n 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�an inapropiado para sistemas transaccionales. Adem�s utilizaba demasiados recursos del cliente que pod�an ser empleados para otros prop�sitos.
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�ncronamente respecto al cliente, el cual guarda todos los bloques de escritura a disco magn�tico, utilizando varias t�nicas de programaci�n para realizar su tarea eficientemente.
En un trabajo futuro se puede mejorar el rendimiento del sistema ENRD para conseguir una verdadera asincron�a entre el cliente y el backup. Su pricipal limitaci�n 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�s apropiadas, como �rboles binarios balanceados, cuando el tama�o de una lista es relativamente grande, podr�a 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�cil de implementar y se requerir�a para poder usar ENRD en sistemas comerciales. Como hemos comentado, la posibilidad de usar una versi�n fiable de Multicast evitar�a dicha implementaci�n a nivel de aplicaci�n. Modificar el dise�o del ENRD para que sea el propio driver en vez del daemon el que se comunique con los servidores remotos ser�a interesante y mejorar�a el rendimiento (esta idea se ha utilizado en el kernel httpd server).
Por �ltimo, un estudio de las posibilidades de ENRD con tecnolog�as de red m�s avanzadas ser�a conveniente, o simplemente con librer�as 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