En el último artículo se abordó la temática del ciclo de vida de las imágenes DICOM. En dicho artículo nos acercamos bastante a los almacenamientos puesto que eran parte fundamental del ciclo de vida de las imágenes. Ahora vamos a ver cuáles son las claves para plantear un almacenamiento de imágenes médicas que sea robusto y esté preparado para el crecimiento futuro.
A la hora de plantear un sistema de almacenamiento tenemos que conocer cómo funciona el hardware sobre el que residirá. No es viable intentar montar una gestión de almacenamiento conociendo solamente como funciona el disco del PC de nuestra casa. Una vez que sepamos las características del hardware, tendremos que tener en cuenta los siguientes puntos:
- Con el tiempo, la cantidad de información almacenada en nuestro sistema crecerá y sobrepasará con creces el terabyte de información.
- El número de imágenes almacenadas será, con el tiempo, de millones.
- El tamaño de las imágenes crece con el tiempo, siendo actualmente, la media de varios megabytes y estando la mamografía digital en decenas de megabytes.
- La velocidad de recuperación es un factor importante.
- El rendimiento no puede caer.
En base a estos puntos tendremos que desarrollar nuestro sistema de almacenamiento de imágenes. Iremos yendo punto por punto analizando las diferentes problemáticas que nos podemos encontrar y posibles soluciones.
Punto 1: Capacidad de Almacenamiento
La capacidad y cantidad de almacenamiento es el punto más importante ya que una mala arquitectura en este punto puede hacer que nuestro sistema se pare. Si hemos gestionado mal este punto, es posible que el sistema llegue un momento en que no sea capaz de gestionar los volúmenes de almacenamiento. Aquí es donde tendremos que conocer el hardware sobre el que vamos a trabajar, las cabinas de almacenamiento empresariales. Existen muchos tipos de cabinas, diferenciadas básicamente en el número de controladoras, el tipo de discos con el que trabajan, la velocidad de transferencia y la capacidad de gestión de tamaño. Lo que tenemos que tener claro son las limitaciones en tamaño y el funcionamiento de los RAIDs de discos.
Tradicionalmente, cuando se gestionaba una cabina de discos, el administrador introducía los discos pertinentes e iba configurando los RAIDs a los discos de la manera: disco1 y disco2 en RAID1, disco3, disco4 y disco5 en RAID5 y así sucesivamente. Los discos tenían que ser del mismo tamaño para que los RAIDs funcionasen. Actualmente, la configuración de la redundancia entre discos se ha virtualizado, de forma que un administrador no tiene que decir sobre qué discos físicos monta un RAID sino que la controladora de la cabina realiza lo que se llama "Leveling" y pone los datos sobre todos los discos, gestionando ella los RAIDs. En el siguiente esquema se ve con mayor claridad este concepto:
Tradicionalmente, cuando se gestionaba una cabina de discos, el administrador introducía los discos pertinentes e iba configurando los RAIDs a los discos de la manera: disco1 y disco2 en RAID1, disco3, disco4 y disco5 en RAID5 y así sucesivamente. Los discos tenían que ser del mismo tamaño para que los RAIDs funcionasen. Actualmente, la configuración de la redundancia entre discos se ha virtualizado, de forma que un administrador no tiene que decir sobre qué discos físicos monta un RAID sino que la controladora de la cabina realiza lo que se llama "Leveling" y pone los datos sobre todos los discos, gestionando ella los RAIDs. En el siguiente esquema se ve con mayor claridad este concepto:
En la virtualización de discos, la controladora interpone una capa que oculta los discos físicos al administrador y le ofrece el tamaño de que dispone. La controladora almacenará los datos donde estime oportuno. Esto permite unas configuraciones mucho más flexibles de los volúmenes de discos a mostrar a los servidores.
Las cabinas, actualmente, limitan el tamaño máximo de los volúmenes a 2 Terabytes. Esto, en un principio puede parecer un tamaño grandísimo, pero en un sistema de almacenamiento dicom, se queda en muy poco. En los servidores se pueden realizar configuraciones de discos dinámicos, pero en determinadas configuraciones de clusteres, los discos dinámicos no son aceptados. Entonces, ¿qué pasa si el volumen donde guardamos las imágenes se llena?, nuestro sistema tendrá que tener previsto esto e implementará alguna estrategia de conmutación. Existen diferentes modelos para implementar esto:
Las cabinas, actualmente, limitan el tamaño máximo de los volúmenes a 2 Terabytes. Esto, en un principio puede parecer un tamaño grandísimo, pero en un sistema de almacenamiento dicom, se queda en muy poco. En los servidores se pueden realizar configuraciones de discos dinámicos, pero en determinadas configuraciones de clusteres, los discos dinámicos no son aceptados. Entonces, ¿qué pasa si el volumen donde guardamos las imágenes se llena?, nuestro sistema tendrá que tener previsto esto e implementará alguna estrategia de conmutación. Existen diferentes modelos para implementar esto:
- Conmutación manual: Es la más obvia y mucha gente no realiza nada en este aspecto. El administrador se encarga de cambiar los parámetros de la aplicación cuando llega el momento.
- Conmutación simple: nuestra aplicación es capaz de detectar cuando un volumen está lleno y cambia al siguiente que tenga configurado.
- Abstracción de volúmenes: esta es la más compleja ocultando los volúmenes al resto del sistema y mostrando una sola ubicación lógica. Internamente gestionará mediante conmutación simple los cambios, detectará fallos de escritura y cambiará, etc.
De esta manera, gestionaremos el espacio en disco e iremos creciendo en volúmenes cuanto como queramos. Nuestro sistema tendrá que proveer de herramientas para incrementar el número de volumenes que se acogen bajo los presentados a la aplicación, o la creación de nuevos grupos de volúmenes, etc.
Punto 2: Número de imágenes
Este es también un factor importante, cada día que vaya pasando el número de ficheros y de registros en base de datos irá creciendo y no disminuirá. Con el tiempo tendremos millones de imágenes. Esto obliga a dos cosas:
- Una buena estructura e indexación de base de datos que permita realizar búsquedas cómodamente, sin tumbar el servidor.
- Una buena estructura de almacenar los ficheros dicom en disco.
La estructura de tablas que define DICOM es buena (Paciente --> Estudio --> Serie --> Imagen), estando en la tabla imagen un puntero al fichero de imágenes. Dependiendo de como hagamos las búsquedas indexaremos unos campos u otros. Lo normal es que las búsquedas se realicen sobre PatientID, PatientName, Modality, StudyDate. Una vez seleccionado el estudio a visualizar, la recuperación se suele hacer por lo UID de los respectivos niveles definidos por DICOM. Por lo tanto, se indexarán estos campos para obtener un rendimiento mejor. Durante el tiempo, los DBA deberán obtener estadísticas para actualizar los índices en caso que hiciese falta.
Con respecto al almacenamiento en disco, es importante que se subdivida y catalogue en diferentes subcarpetas para no tener millones de ficheros dentro de una carpeta. Como en todo, existen diferentes sistemas y estrategias a seguir en este punto:
- Almacenar por los UIDs de la imagen, creando una estructura del tipo PatientID / StudyUID / SeriesUID / y dentro de éste las imágenes, nombradas como ImageUID.dcm.
- Crear una estructura por fecha de estudio, teniendo directorios del tipo año / mes / día y dentro las imágenes
- Crear su propio sistema de almacenamiento.
Personalmente, el que prefiero es el primero, aunque cada uno puede implementar el que más le interese. Una vez decidido nuestra estrategia de almacenamiento en disco, pasamos al tercer punto a tener en cuenta.
Punto 3: Tamaño de las imágenes
¿Por qué es importante este aspecto? No es por el almacenamiento, que ya hemos resuelto, sino por los lenguajes de programación y la memoria de los servidores. Un sistema de almacenamiento tendrá una actividad grande de entrada y salida de imágenes y cuanto más sea utilizado mayor. La actividad se traduce en movimiento de imágenes, montaje en memoria de las mismas y copia en archivo. Esto con múltiples hilos de ejecución a la vez. Lo que significa es que el servidor necesitará una cantidad de memoria grande, pero lo más importante es que necesitaremos un lenguaje de programación que sea capaz de gestionar esa memoria. Los lenguajes de programación, cuanto de más bajo nivel sean, mejor gestionarán este aspecto. Java o C# pueden tener complicaciones al poner muchas capas de abstracción, máquinas virtuales, servidores de aplicación, elementos que consumen recursos. C o C++ serán mucho más ágiles aunque tendremos el problema de que cuanto más bajamos más nos atamos a la plataforma. Estará en manos del responsable del desarrollo el sopesar los pros y contras de cada lenguaje y tomar un camino.
Punto 4: La velocidad
En todos los sistemas de almacenamiento dicom, la velocidad es un factor muy importante y suele ser uno de los baremos por los que se miden. Si nuestra arquitectura es buena, nuestra política de almacenamiento es buena, tenemos bien indexada la base de datos y el lenguaje de programación responde velozmente, entonces no tendremos problemas con este aspecto. Si tenemos problemas con la velocidad tendremos que revisar los puntos anteriores y si no es el caso, veamos el punto siguiente.
Punto 5: El rendimiento
Los sistemas de almacenamiento suelen ir creciendo en usuarios y la demanda se incrementa con el tiempo. Sin embargo, el rendimiento no puede decaer, por lo que tenemos que tener esto en cuenta al diseñar nuestra arquitectura. Existen varios tipos de arquitectura que se pueden aplicar a la hora de diseñar un sistema de almacenamiento de imágenes dicom:
Con esto tendremos nuestro sistema de almacenamiento en disco completo. Como siempre, espero que os gusten los artículos. En próximas entregas profundizaremos en el backup de las imágenes, que al fin y al cabo es otro sistema de almacenamiento.
Punto 3: Tamaño de las imágenes
¿Por qué es importante este aspecto? No es por el almacenamiento, que ya hemos resuelto, sino por los lenguajes de programación y la memoria de los servidores. Un sistema de almacenamiento tendrá una actividad grande de entrada y salida de imágenes y cuanto más sea utilizado mayor. La actividad se traduce en movimiento de imágenes, montaje en memoria de las mismas y copia en archivo. Esto con múltiples hilos de ejecución a la vez. Lo que significa es que el servidor necesitará una cantidad de memoria grande, pero lo más importante es que necesitaremos un lenguaje de programación que sea capaz de gestionar esa memoria. Los lenguajes de programación, cuanto de más bajo nivel sean, mejor gestionarán este aspecto. Java o C# pueden tener complicaciones al poner muchas capas de abstracción, máquinas virtuales, servidores de aplicación, elementos que consumen recursos. C o C++ serán mucho más ágiles aunque tendremos el problema de que cuanto más bajamos más nos atamos a la plataforma. Estará en manos del responsable del desarrollo el sopesar los pros y contras de cada lenguaje y tomar un camino.
Punto 4: La velocidad
En todos los sistemas de almacenamiento dicom, la velocidad es un factor muy importante y suele ser uno de los baremos por los que se miden. Si nuestra arquitectura es buena, nuestra política de almacenamiento es buena, tenemos bien indexada la base de datos y el lenguaje de programación responde velozmente, entonces no tendremos problemas con este aspecto. Si tenemos problemas con la velocidad tendremos que revisar los puntos anteriores y si no es el caso, veamos el punto siguiente.
Punto 5: El rendimiento
Los sistemas de almacenamiento suelen ir creciendo en usuarios y la demanda se incrementa con el tiempo. Sin embargo, el rendimiento no puede decaer, por lo que tenemos que tener esto en cuenta al diseñar nuestra arquitectura. Existen varios tipos de arquitectura que se pueden aplicar a la hora de diseñar un sistema de almacenamiento de imágenes dicom:
- Sistema en cluster: diseñamos nuestro sistema para que se pueda clusterizar, haciendo que el sistema operativo controle su operatividad. En estos entornos, nuestra solución será activa - pasiva. Esto realmente no incrementa nuestro rendimiento, sino nuestra disponibilidad. Sin embardo, si programamos de manera que podamos distribuir en el cluster nuestro sistema en módulos separados, podremos realizar un balanceo manual de las funcionalidades.
- Sistema balanceado: esta es la mejor opción porque podemos tener nuestro sistema corriendo de manera simultánea en varios servidores de manera activa-activa, multiplicando el rendimiento por el número de servidores. Es más complejo puesto que tenemos que lo tenemos que tener en cuenta a la hora de programar.
- Sistema simple: no implementamos ninguna estrategia y le ponemos más recursos a los servidores.
Con esto tendremos nuestro sistema de almacenamiento en disco completo. Como siempre, espero que os gusten los artículos. En próximas entregas profundizaremos en el backup de las imágenes, que al fin y al cabo es otro sistema de almacenamiento.
No hay comentarios:
Publicar un comentario