libretadigital.com

El servidor MarisaDiskPool de MarisaFileSystem permite crear, borrar, leer, escribir y sincronizar replicas de bloques de datos de tamaño arbitrario. A partir de ahora se distinguen los términos bloque y réplica de bloque:

• Réplica de bloque es una copia determinada en un diskpool determinado de los datos de un bloque, que puede estar o no sincronizada con el estado más reciente de dicho bloque.
• Bloque es una entidad abstracta que representa un bloque de datos replicado en N veces (frecuentemente 3). El bloque podrá leerse de la réplica maestra o las replicas esclavas sincronizadas (las que están al día de los datos escritos en dicho bloque).

Las escrituras son atómicas, se realizan completamente o se deshacen del todo.

El servidor diskpool permite lecturas y escrituras concurrentes de bloques de datos:

Requisitos Generales:

• RG1. Cada bloque es completamente independiente de los demás. Solo se compite por espacio de almacenamiento.
• RG2. Cada diskpool contiene una sola réplica de algunos de los bloques del sistema (agrupación de diskpools).
• RG2. Cada réplica de bloque tiene un tamaño máximo, pero un mismo diskpool puede contener bloques de diferentes tamaños. (No obstante, los bloques generalmente formarán parte de abstracciones superiores como ficheros donde lo lógico es que todos lo bloques de un mismo fichero cuenten con un mismo tamaño de bloque máximo fijo.)
• RG3. Una réplica de bloque al crearse o al (re)iniciarse el diskpool está siempre desincronizada: No admite operaciones de lectura o escritura hasta que se marque como réplica maestra o como réplica esclava sincronizada.

Creación de Réplica:

• RC1. Una réplica de bloque podrá ser creada por el diskpool solo si no existía previamente y se ha pedido con un tamaño máximo legal, es decir, mayor que 0 y menor que el mayor tamaño de bloque posible o el espacio disponible. La replica recién creada está en la versión 0 y desincronizada.

Sincronización de Réplicas:

• RS1. Se selecciona la réplica maestra de un bloque (una de las que tengan la versión de bloque más alta) y se le envía a su diskpool una petición de sincronización de réplicas, que incluye una lista de los diskpools que contienen el resto de réplicas del bloque a sincronizar, las réplicas esclavas.
• RS2. El diskpool receptor, elegido maestro de réplica, debe confirmar que todas las réplicas esclavas en los diskpools dados han sido notificadas y han confirmado o rechazado la petición. Las razones de rechazo pueden ser:

FATALES: versión ilegal (la versión de la réplica esclava es superior a la del maestro)

NO FATALES: diskpool no disponible o timeout o error interno del diskpool.

• RS3. La petición de sincronización incluye tambien un número mínimo de réplicas aceptable para que la petición tenga éxito. Por ejemplo, puede haberse enviado una lista con 2 réplicas esclavas (replicación 1+2) pero puede bastar que haya 2 réplicas activas (la maestra y una esclava), con lo cual se toleraría que uno de los 2 diskpool consultados no confirmase la notificación. No obstante, un solo  ERROR FATAL de cualquier diskpool hace fallar la petición de sincronización.
• RS4. Un diskpool esclavo que recibe una notificación de una réplica:

Si esta no existe la crea y devuelve en la confirmación la versión 0.

Si ya existía devuelve la versión que tenga la réplica en ese momento.

• RS5. Tras responder al cliente según las confirmaciones de las réplicas esclavas, la réplica maestra usa estas confirmaciones para decidir en cada réplica el tipo de sincronización:

Dar por sincronizada la replica si tiene una versión y HASH igual a la suya.

O sincronizarla, enviando todos los octetos del ultimo estado de la réplica maestra.

• RS6. Ni la replica maestra ni las esclavas guardan su condición de manera persistente. Si el proceso del diskpool cae habrán olvidado todo esto y la réplica volverá a estar desincronizada. Si la replica caída era esclava, la maestra contactará con ella y la sincronizará de nuevo. Si la que cayó era la maestra habrá que repetir la petición de sincronización a la nueva réplica maestra seleccionada.

Lectura de un bloque sincronizado:

• RL1. Cada lectura obtiene acceso sin esperar a otros lectores o escritores a la ultima versión consistente de la réplica de bloque.
• RL2. Aunque se estén realizando varias escrituras concurrentes a la lectura, estas no modifican la versión leída del bloque.
• RL3. Varias lecturas concurrentes sobre la misma réplica de bloque podrían estar leyendo versiones diferentes; la lectura que llegó más tarde lee la versión más moderna.
• RL4. El acceso al bloque (en lectura y escritura) será aleatorio, pudiendo empezar por cualquier octeto y acabando en cualquier otro, pero siempre un solo sentido, del principio hacia el final.
• RL5. Las réplicas de bloque no están obligadas a guardar ninguna versión más antigua que la que esté leyendo el lector más antiguo en ese momento.
• RL6. La petición de lectura incluye un número de versión mínimo esperado, la operación solo se acepta si la réplica ha sido sincronizada por el maestro Y la versión que contiene es igual a posterior a la que espera el lector, sino la réplica rechaza la petición.

Escritura del bloque:

• RE1. Una escritura tiene siempre dos partes:

El envío de datos de la escritura.

La confirmación o cancelación de la escritura del bloque.

• RE2. Si el envío de datos se dirige primero a la réplica maestra, la escritura se puede hacer autoconfirmada, de manera que al llegar a final sin errores la réplica maestra la confirmará en esta y en las réplicas esclavas que la hayan recibido totalmente.
• RE3. Si el envío de datos llega primero a una réplica esclava, la confirmación debe hacerse por separado y siempre a la réplica maestra. Por supuesto, la réplica maestra debe haber recibido los datos tambien para poder confirmar la escritura. De esta manera la réplica esclava decide un orden único para las escrituras en el bloque.
• RE4. Cada escritura no es visible o efectiva hasta que finalmente se confirma en la réplica maestra, incrementando el número de versión del bloque.
• RE5. Si el diskpool de la réplica maestra cae, las escrituras de bloque en curso (no confirmadas) desparecen completamente y sufren una cancelación automática.
• RE6. Los diskpool no acepta datos por encima del ultimo octeto permitido según el tamaño máximo del bloque y responde cortando la conexión. Por ejemplo, si la escritura empezó en la posición 700.000 y el bloque tiene un tamaño máximo de 1.000.000 y ya han llegado 300.000 octetos, la escritura se da por terminada en recepción. Si el receptor era la réplica maestra y se trataba de una escritura autoconfirmada se procede a confirmar la escritura y si no, se espera a recibir la confirmación en la réplica maestra.
• RE7. El envió de datos entre las réplicas del bloque se realiza en cadena en el orden indicado en la propia petición. El tiempo de escritura será (Noct*Ab)+(2*Nr*L) donde:

Noct son los octetos escritos.

Ab es el ancho de banda mínimo de la red (en octetos/s).

Nr es el número de réplicas en las que se está escribiendo.

L es la latencia media en la red.

• RE8. La confirmación de escritura, como ya se ha dicho, solo puede hacerla la réplica maestra. La replica maestra localiza los datos de escritura recibidos y los aplica incrementa el número de versión que le corresponderá a esa escritura del bloque. Si algún error se lo impide se produce una cancelación informando solamente al cliente, no es necesario informar a las réplicas esclavas que ya borrarán los datos no confirmados una vez caducados.
• RE9. Si la réplica maestra pudo realizar la confirmación de la escritura localmente, avisa a las réplicas esclavas citadas en la confirmación de escritura para sincronizarlas. Con las respuestas de todas las réplicas (incluidas respuestas por timeout) se responde al cliente con éxito (todas las réplicas están sincronizadas) o desincronismo porque la escritura fue realizada solo en algunas réplicas, la réplica maestra pasa a desincronizada y cancela todas las operaciones de escritura pendientes.
• RE10. Tras un desincronismo la escritura en que se produjo se considera que ha tenido éxito (parcial), pero el bloque no aceptará más operaciones de escritura  hasta que se produzca una nueva sincronización del bloque, lo más frecuente es que la antigua réplica maestra reciba la petición de sincronización de nuevo pero excluyendo la réplicas que fallaron.

Destrucción de Réplica y Bloque:

• RD1. La destrucción de una réplica de bloque espera a que acaben las lecturas pendientes para hacerse efectiva.

• RD2. Por otro lado, nada más recibir y aceptar la orden de destrucción de réplica las escrituras pendientes (envíos de datos en curso) son abortados y no se aceptan confirmaciones de escritura en esta réplica.
• RD3. Si la réplica borrada es la maestra debe ir marcada como borrado de bloque y las réplicas esclavas son notificadas por la maestra para que se borren también.
• RD4. Es responsabilidad del sistema cliente (el que use el diskpool) anotar que bloques han sido borrados por completo, de manera que si el diskpool levanta con alguna réplica que debería haber desaparecido ya el sistema sabrá que debe borrarla de alguna forma (por ejemplo, por no estar asociado el bloque a ningún fichero).

---

Diskpool by José Luis Vázquez González is licensed under a Creative Commons Reconocimiento-No comercial-Compartir bajo la misma licencia 2.5 España License.