Últimos Cambios
Blog personal: El hilo del laberinto
|
|
|
Últimos Cambios |
|
Blog personal: El hilo del laberinto
|
|
|
Última Actualización: 10 de enero de 2012
Hasta donde yo sé, ZFS es el único sistema de ficheros de uso mínimamente popular que permite combinar el uso de discos duros normales con memorias FLASH (SSD = Solid-State Disk) de forma transparente y combinando lo mejor de ambos mundos.
Lo discos duros son razonablemente rápidos para acceso "streaming" (acceso a datos contiguos, no acceso aleatorio) y tienen una gran capacidad a un coste reducido.
Aunque tecnológicamente los SSD puedan proporcionar un ancho de banda arbitrariamente alto (simplemente juntando más chips en el paquete y accediéndolos en paralelo) y que habitualmente su consumo energético sea inferior a un disco duro equivalente, su principal ventaja es que carecen de "seek time". Es decir, que a la hora de acceder al SSD, da lo mismo que los datos estén contiguos a que estén repartidos de forma aleatoria.
Un disco duro es un dispositivo mecánico sujeto a fatiga y a inercias físicas. Por mucha ingeniería que metamos, son límites físicos que pueden mejorarse pero no romperse.
Eventualmente, el coste por gigabyte de los SSD bajará por debajo del de los discos duros, momento en que éstos quedarán obsoletos. Mientras tanto casi todos los sistemas te obligan a elegir: usar disco duro o usar SSD. Muchos servidores incorporan ambos dispositivos, y el administrador debe particionarlos y decidir qué aloja en cada uno. Por ejemplo, la base de datos en el SSD, porque la velocidad de acceso aleatorio es importante, y lo que se usa poco o cuya velocidad de acceso es menos crítica, en el disco duro, que es más barato y tiene mucha más capacidad.
En todo caso, es una decisión explícita del administrador de sistemas. Si la base de datos crece hasta superar la capacidad de memoria del SSD, no podemos sino comprar otra más grande, ya que alojarla en el disco duro no nos proporciona el rendimiento que necesitamos.
En ZFS no es así. En ZFS podemos unir un "pool" de discos duros (puede ser un disco o docenas) a un número cualquiera (uno o docenas) de SSD's. Y no asignamos cada recurso de forma estática para un "dataset", sino que pertenecen a todo el "pool" y su uso es automático y transparente.
Básicamente las SSD se utilizarán como sistema de caché transparente. Veamos los dos casos: lectura y escritura.
ZFS utiliza un sistema de caché en RAM llamado ARC (Adaptive Replacement Cache). Este algoritmo es bastante más avanzado y complejo que el LRU, por ejemplo, pero se comporta mejor que éste ante situaciones patológicas típicas, como que copiar ficheros grandes de un sitio a otro desaloje de la caché objetos de uso frecuente, que tendrán que leerse de nuevo del disco duro enseguida.
Pero por muy bueno que sea el algoritmo, y aunque que el sistema operativo utilice los 24 gigabytes del servidor como caché, lo cierto es que si estamos manejando datos de forma activa con un tamaño superior a nuestra capacidad de RAM al final tendremos que "tirar" datos de la memoria que, tarde o temprano, habrá que volver a leer del disco duro.
Pero podemos definir un dispositivo del "pool" ZFS como "L2ARC". Es decir, "ARC de nivel 2". La idea es que los objetos que ya no caben en la RAM (el ARC), en vez de eliminarlos de memoria y recargarlos de disco de nuevo cuando sean necesarios, se envían al dispositivo (o dispositivos) L2ARC. Si la lectura del L2ARC es más rápida que acceder al disco original, tenemos una ganancia de rendimiento.
Normalmente el dispositivo L2ARC será una SSD, pero no es necesario. Por ejemplo, si los datos originales residen en un dispositivo iSCSI remoto, usar un disco duro local rápido como L2ARC puede ser una ganancia sustancial en ancho de banda y en velocidad. ZFS usará como L2ARC el dispositivo o dispositivos que le indiquemos.
Algunas características de L2ARC en las versiones actuales de ZFS:
Este detalle hace también que asignar un dispositivo "grande" como L2ARC puede ser un desperdicio que no aporta ningún beneficio. Por ejemplo, si creamos un L2ARC en un disco de un terabyte, tardaríamos mucho (posiblemente, nunca) en llenarlo. No compensa. Por no olvidar el consumo de memoria RAM que supondría. Por otro lado, contendría datos de uso tan infrecuente que ir al disco duro "real" a por ellos no afecta al rendimiento.
La regla habitual es que 100GB de L2ARC ocupan 1-2GB de RAM real. Pero la cifra exacta depende del tamaño de bloque efectivo de ZFS.
Debido a esto y al punto anterior, no es inteligente usar "mirrors" como L2ARC. En general, sobre todo con el tamaño actual de las SSD, es preferible utilizar dos SSD como "stripping", duplicando la capacidad y el ancho de banda del L2ARC.
Cuando se guarda un dato en el L2ARC, se le calcula una suma de control que se mantienen en RAM, de forma que podemos verificar su integridad cuando se lee, aunque el dispositivo no nos indique ningún error.
Solaris 10 y derivados proporcionan estadísticas interesantes y detalladas sobre ARC y L2ARC. Por ejemplo, en un servidor sin L2ARC puedo ver lo siguiente:
[root@XXX /]# kstat zfs::arcstats
module: zfs instance: 0
name: arcstats class: misc
c 10212435301
c_max 24678334464
c_min 3084791808
crtime 77.32556706
data_size 8770825216
deleted 19154548
demand_data_hits 4415206368
demand_data_misses 5057241
demand_metadata_hits 9148538352
demand_metadata_misses 3213951
evict_l2_cached 0
evict_l2_eligible 739645837312
evict_l2_ineligible 42101163520
evict_skip 2159701
hash_chain_max 15
hash_chains 305112
hash_collisions 326041988
hash_elements 1026344
hash_elements_max 1587374
hdr_size 202097704
hits 13596352582
l2_abort_lowmem 0
l2_cksum_bad 0
l2_evict_lock_retry 0
l2_evict_reading 0
l2_feeds 0
l2_free_on_write 0
l2_hdr_size 0
l2_hits 0
l2_io_error 0
l2_misses 0
l2_read_bytes 0
l2_rw_clash 0
l2_size 0
l2_write_bytes 0
l2_writes_done 0
l2_writes_error 0
l2_writes_hdr_miss 0
l2_writes_sent 0
memory_throttle_count 0
mfu_ghost_hits 4091225
mfu_hits 13314858371
misses 14457327
mru_ghost_hits 3114547
mru_hits 249049566
mutex_miss 40351
other_size 1236206768
p 9193395515
prefetch_data_hits 5728937
prefetch_data_misses 5098302
prefetch_metadata_hits 26878925
prefetch_metadata_misses 1087833
recycle_miss 857241
size 10209129688
snaptime 8599864.1085979
La máquina tiene un "uptime" de tres meses. No tiene configurado L2ARC (aún), pero vemos que Solaris hubiera movido al L2ARC unos 700 gigabytes, de haber podido. Eso no significa que necesitemos 700GB para el L2ARC, por dos motivos:
Acelerar las lecturas supone un aumento de rendimiento inmediato porque casi ninguna aplicación puede realizar ningún tipo de progreso hasta que recibe el dato leído. A la hora de escribir, en cambio, lo importante es disponer de ancho de banda suficiente al disco para nuestra aplicación. Pero la latencia de escritura no importa en la mayoría de los casos. De hecho cualquier sistema operativo moderno decente acumulará unos segundos de actividad en RAM y luego los volcará en una ráfaga al disco duro, sin que las aplicaciones sean conscientes de estos detalles. Esta acumulación permite muchas optimizaciones, como evitar toda actividad de disco para ficheros creados, modificados, leídos y borrados en rápida sucesión (por ejemplo, ficheros de intercambio entre programas), o colapsar muchas escrituras cortas en una larga y eficiente escritura larga. O planificar con detalle la asignación de posiciones de los datos en el disco duro. Y todo automático y transparente a las aplicaciones, que dan la orden de grabación al sistema operativo y se olvidan.
Pero hay un caso donde la velocidad de escritura es importante, crucial: las escrituras síncronas.
Las escrituras "cacheadas" en memoria, las normales, son escrituras asíncronas. Los programas piden que se grabe un dato y el sistema operativo lo hará "cuando le parezca". Un tiempo normal de "cacheo" es, por ejemplo, 30 segundos. El problema es que si se va la luz, el sistema se cuelga, el ordenador empieza a echar humo, etc., podemos perder esos 30 segundos de grabaciones pendientes. Es decir, podemos estar escribiendo nuestra tesis doctoral, grabarla y tirar del cable del ordenador a los diez segundos... y haber perdido el fichero que grabamos "hace" diez segundos.
La mayor parte del tiempo no importa mucho. Un servidor se reinicia una vez al mes (hay que parchearlo :) de forma controlada, y permitiendo que las escrituras sean asíncronas la mejora de velocidad es apabullante.
Pero existen casos donde debemos garantizar que los datos se han grabado en el disco duro de forma fehaciente. Por ejemplo, cuando llega un mensaje de correo electrónico a nuestro servidor, no debería darle el OK al remitente HASTA haberse asegurado de que el mensaje se ha grabado realmente en el disco duro. No podemos permitir que el ordenador se cuelgue y se pierda un correo electrónico. Eso es intolerable. O no queremos que nuestro balance bancario quede inconsistente. Otro ejemplo donde las escrituras síncronas son importantes es el caso de un servidor NFS.
En el caso del procesador de texto, las copias de seguridad periódicas que hace el programa automáticamente pueden ser grabaciones asíncronas (y que mantenga un histórico, porque la última puede estar incompleta), pero estaría bien que cuando el usuario pulsa sobre "save", el fichero se "grabe de verdad". Ahora.
En el mundo de las bases de datos se habla de ACID. La "D" significa "Durabilidad". Es decir, que una vez que la base de datos se hace cargo de un dato, este dato no se va a perder por "chorraditas" menores que un incendio en el datacenter. O una bomba atómica. Pero, desde luego, no porque alguien tropiece con el enchufe.
El problema es, nuevamente, que los discos duros son dispositivos mecánicos sujetos a leyes físicas. Son lentos, comparados con la electrónica, sobre todo cuando empezamos a mover el cabezal del disco duro de un lado para otro. ZFS utiliza ZIL (ZFS Intention Log) para completar las grabaciones síncronas "rápido", a poder ser sin mover el cabezal del disco duro (gracias a que ZFS es un sistema CoW, "Copy on Write"). Comparado con otros sistemas de ficheros, ZFS es muy rápido en escrituras síncronas, siendo muy fácil obtener 3-4 veces más transacciones por segundo que otros sistemas de ficheros modernos, si los datos a escribir son pocos. 120 transacciones por segundo en un disco "normal" de 7200 RPM es rutina.
Pero un SSD "normal" me permite hacer más de 5000 escrituras síncronas por segundo. Eso son casi dos órdenes de magnitud por encima. Y esto es con la tecnología actual, que no está limitada por restricciones mecánicas como mover el cabezal a la otra punta del disco duro, o esperar a que el disco rote hasta que el sector que nos interesa pase por debajo del cabezal.
ZFS permite poner el ZIL en el dispositivo separado. Puede ser una SSD o un disco duro pequeño pero rápido (digamos, un disco de 72GB de 15.000 RPM). Las escrituras asíncronas, que son la mayoría, se guardan en el disco duro como siempre, tras un pequeño tiempo en memoria. Las escrituras síncronas se guardan en el ZIL, en un dispositivo rápido, pero permanecen en memoria como siempre y serán volcados al disco duro de forma normal tras ese período de cacheo temporal en RAM. De hecho el ZIL es prácticamente escrituras en exclusiva. Solo se lee al reiniciar el sistema, para comprobar si hay transacciones pendientes de grabar en el disco duro. El resto del tiempo solo se escribe.
Algunos detalles:
[root@XXX z-dtrace]# ./zilstat.ksh -t -p datos txg waiting for txg commit... TIME txg N-Bytes N-Bytes/s N-Max-Rate B-Bytes B-Bytes/s B-Max-Rate ops <=4kB 4-32kB >=32kB 2012 Jan 5 19:30:48 619068 476512 17648 299024 1347584 49910 524288 11 0 0 11 2012 Jan 5 19:31:18 619069 445616 14853 119152 4775936 159197 598016 41 1 0 40 2012 Jan 5 19:31:48 619070 2907760 96925 2860440 3575808 119193 3014656 28 0 0 28 2012 Jan 5 19:32:18 619071 666240 22208 409688 2527232 84241 1122304 26 1 0 25 2012 Jan 5 19:32:48 619072 278248 9274 142248 1212416 40413 430080 15 0 0 15 2012 Jan 5 19:33:18 619073 803400 26780 363296 3067904 102263 524288 33 1 0 32 2012 Jan 5 19:33:48 619074 82280 2742 45136 466944 15564 262144 5 0 0 5 2012 Jan 5 19:34:18 619075 1139568 37985 306712 3584000 119466 917504 47 1 0 46 2012 Jan 5 19:34:48 619076 49656 1655 49656 503808 16793 503808 6 0 0 6 2012 Jan 5 19:35:18 619077 4127464 137582 2807424 6348800 211626 2883584 62 1 2 59 2012 Jan 5 19:35:48 619078 181048 6034 80864 634880 21162 262144 7 0 0 7 2012 Jan 5 19:36:18 619079 786864 26228 544536 3895296 129843 1122304 35 1 0 34 2012 Jan 5 19:36:48 619080 850440 28348 715624 2002944 66764 917504 16 0 0 16 2012 Jan 5 19:37:18 619081 1198856 39961 404856 5578752 185958 823296 50 1 0 49 2012 Jan 5 19:37:48 619082 305360 10178 117160 2134016 71133 786432 17 0 0 17 2012 Jan 5 19:38:18 619083 816240 27208 294320 4993024 166434 1179648 45 1 1 43 2012 Jan 5 19:38:48 619084 2915080 97169 2820680 3432448 114414 2883584 28 0 2 26 2012 Jan 5 19:39:18 619085 625152 20838 302808 2576384 85879 786432 39 1 6 32 2012 Jan 5 19:39:48 619086 198328 6610 48400 2396160 79872 671744 32 0 8 24 2012 Jan 5 19:40:18 619087 1120288 37342 775032 2473984 82466 1048576 37 1 11 25 2012 Jan 5 19:40:48 619088 194720 6490 135560 692224 23074 262144 8 0 3 5 2012 Jan 5 19:41:18 619089 58749672 1958322 58147816 69685248 2322841 65966080 540 1 1 538 2012 Jan 5 19:41:48 619090 340008 11333 67136 2785280 92842 536576 33 0 9 24 2012 Jan 5 19:42:18 619091 3623800 120793 2612088 6569984 218999 2752512 68 1 2 65 2012 Jan 5 19:42:48 619092 1039200 34640 903920 1347584 44919 1179648 11 0 0 11 2012 Jan 5 19:43:18 619093 672104 22403 358896 2379776 79325 524288 31 1 2 28 2012 Jan 5 19:43:48 619094 47096 1569 47096 167936 5597 167936 2 0 0 2 ^C
Vemos que ZFS genera una transaccion ZFS nueva cada 30 segundos (en algunos casos el tiempo puede ser menor, como cuando se hace un "snapshot" ZFS), y las escrituras síncronas durante cada período se canalizan al ZIL, que es lo que estamos midiendo con ese script DTrace. Como no tengo configurado aún un ZIL en la SSD, el ZIL (en realidad uno por cada "dataset") se guarda en los discos duros del propio ZPOOL.
En este caso la transacción más "cargada" generó unos 70MB en 30 segundos, aunque el tráfico medio sea muy inferior. Y 540 transacciones. La flash puede absorber fácilmente 5.000 transacciones por segundo, mientras que el disco duro, con suerte, llega a 120 transacciones por segundo (y eso si usas ZFS, que es muy eficiente al respecto).
Digamos que nuestro tráfico medio son 70MB por 30 segundos. ¿Qué tamaño necesitamos para el ZIL?. Pues del orden de 2-3 veces más que el tráfico medio (estamos recopilando una transacción nueva mientras estamos grabando la anterior). En este caso iríamos sobradísimos con 200MB.
Como puede verse, el tamaño del ZIL puede ser pequeño, pero la diferencia de rendimiento es brutal.
En mi servidor tengo dos SSD's de 40GB. Los particiono de la siguiente forma, como explico en otro documento: 8 GB como partición de recuperación (con OpenIndiana), 2 GB como ZIL y 27GB para el L2ARC.
Lo primero que hago es comparar el tráfico medio sostenido en lecturas aleatorias, en el disco duro y en el SSD. Usaré el siguiente programa en Python:
#!/usr/bin/env python
import sys, threading, Queue, time, random
timeout = 10
done = False
if len(sys.argv) != 4+1 :
print >>sys.stderr, "%s device maxsize num_threads blocksize" %sys.argv[0]
sys.exit(1)
device, maxsize, num_threads, blocksize = sys.argv[1:]
maxsize = int(maxsize)*1024*1024*1024
num_threads = int(num_threads)
blocksize = int(blocksize)
q = Queue.Queue()
def worker() :
f = open(device, "rb")
rnd = random.Random()
num_blocks = maxsize//blocksize
n = 0
while not done :
f.seek(blocksize*rnd.randrange(0, num_blocks))
a = f.read(blocksize)
n += 1
q.put(n)
t = []
for i in xrange(num_threads) :
i = threading.Thread(target = worker)
i.setDaemon(True)
i.start()
t.append(i)
time.sleep(timeout)
done = True
transfered = 0
for i in t :
i.join()
transfered += q.get()
bps = transfered/(timeout+0.0)
print "%.1f bloques/s, %.1f bytes/s" %(bps, blocksize*bps)
Para comprobar el disco duro, quito una unidad del "mirror", para que el tráfico "normal" no afecte a la medida. Ejecuto el programa sobre el disco duro "offline":
[root@XXX datos]# zpool offline -t datos c4t3d0s0
[root@XXX datos]# zpool status
pool: datos
state: DEGRADED
status: One or more devices has been taken offline by the administrator.
Sufficient replicas exist for the pool to continue functioning in a
degraded state.
action: Online the device using 'zpool online' or replace the device with
'zpool replace'.
scan: scrub repaired 0 in 8h7m with 0 errors on Sun Jan 1 02:34:18 2012
config:
NAME STATE READ WRITE CKSUM
datos DEGRADED 0 0 0
mirror-0 DEGRADED 0 0 0
c4t2d0s0 ONLINE 0 0 0
c4t3d0s0 OFFLINE 0 0 0
errors: No known data errors
Una vez que terminamos con el disco duro, restauro el "mirror", que ya me estaba poniendo nervioso:
[root@XXX datos]# zpool online datos c4t3d0s0
[root@XXX datos]# zpool status
pool: datos
state: ONLINE
scan: resilvered 258M in 0h1m with 0 errors on Thu Jan 5 21:26:19 2012
config:
NAME STATE READ WRITE CKSUM
datos ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
c4t2d0s0 ONLINE 0 0 0
c4t3d0s0 ONLINE 0 0 0
errors: No known data errors
Obsérverse como ZFS realiza una sincronización incremental de los discos en espejo, muy eficiente.
| 512 bytes | 1 Kbyte | 2 Kbytes | 4 Kbytes | 8 Kbytes | 16 Kbytes | 32 Kbytes | 64 Kbytes | 128 Kbytes | 256 Kbytes | 512 Kbytes | 1 Mbytes | |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Disco duro | 32/62 | 65/127 | 128/258 | 261/516 | 526/1035 | 1001/1946 | 1986/3185 | 3867/4862 | 7209/- | 13029/- | 22073/- | 32506/- |
| Unidad SSD | 3907/14853 | 7800/29733 | 15606/59474 | 30818/119419 | 61095/239162 | 67066/238969 | 67777/239016 | 76454/239069 | 89129/239298 | 98382/239206 | 102813/239337 | 104858/240543 |
La tabla muestra dos valores por casilla: la velocidad de transferencia con un único hilo, y la velocidad de transferencia óptima lanzando varios hilos para proporcionar varias peticiones al sistema operativo y al disco duro, para que pueda procesarlas y reordenarlas como les parezca. No indico el número de hilos para llegar a ese valor óptimo, pero suele rondar los 32 hilos en paralelo. Si indico "-" significa que lanzar más de un hilo es contraproducente, porque las peticiones se hacen competencia entre sí. Es el caso de las transferencias largas, donde si hay dos peticiones concurrentes, el disco duro mueve el cabezal entre ellas, en vez de realizar una larga transferencia sin movimiento mecánico.
En el caso de la memoria SSD la penalización de las transferencias cortas es muy evidente también, aunque se recupera muy rápido. Asimismo, lanzando unos pocos hilos es muy fácil llegar al límite de transferencia de 240MB/s. Otro detalle interesante es que muchas peticiones concurrentes no afectan demasiado al rendimiento, lo que es consistente con el hecho de que las SSD no tengan "seek time".
El disco duro tiene una velocidad de transferencia que varía por la posición de la cabeza (en la parte exterior del disco, la transferencia es más rápida). Además, para obtener la velocidad máxima de transferencia es necesario que la cabeza no se mueva, así que la ráfaga a transferir debe ser muy larga. En cuanto hay competencia por el acceso a disco, el rendimiento cae. Con un tamaño de bloque de 128KB en ZFS, en el peor de los casos estaríamos utilizando apenas el 9% del ancho de banda del disco duro.
Quiero señalar, no obstante, que estas cifras representan el peor de los casos para el disco duro, y que no son representativas del rendimiento típico. En la práctica suele existir bastante localidad de referencia y el rendimiento es mucho mejor. Estas cifras representan el caso pesimista de tráfico aleatorio de disco, que solo se cumpliría en la práctica en casos extremos, como una base de datos inmensa (cientos de gigabytes) con un acceso aleatorio a la misma. De hecho en condiciones normales se llega fácilmente a los 100-120MB/s por disco. 240MB/s con dos discos.
Activemos ahora L2ARC. Como he comentado en la sección correspondiente, no utilizo redundancia porque no aporta nada y es preferible incrementar su capacidad y ancho de banda:
