Procedimiento de diseño de Sistemas de Almacenamiento para Centros de Datos en Pyme ern

PORTADA
PROCEDIMIENTO DE DISEÑO DE SISTEMAS DE
ALMACENAMIENTO PARA CENTROS DE DATOS
Arturo N. Díaz Crespo
MSc. Lilia R. García Parellada
Dr. Alain A. Garófalo Hernández
La Habana 2017

Universidad Tecnológica de La Habana
Facultad de Telecomunicaciones y Electrónica
Departamento de Telecomunicaciones y Telemática
“PROCEDIMIENTO DE DISEÑO DE SISTEMAS DE ALMACENAMIENTO PARA CENTROS DE DATOS”
Trabajo de Diploma en opción al título de Ingeniero en Telecomunicaciones y Electrónica
Autor: Arturo N. Díaz Crespo
Tutores: MSc. Lilia Rosa García Perellada
Dr. Alain A. Garófalo Hernández
La Habana, 2017

FRASE
“La teoría es cuando uno sabe todo y nada funciona,
la práctica es cuando todo funciona y nadie sabe por qué”
Albert Einstein

AGRADECIMIENTOS
En primer lugar, agradezco a mi tutora por siempre estar presente y por sus minuciosas
revisiones y recomendaciones, así como por dejarme la libertad de actuar a la hora de probar
en la práctica algún que otro concepto. Gracias por la paciencia que ha tenido al trabajar
conmigo, que es mucha!!!
A mi equipo “aguerrido y trabajador” Ariel, Clavijo, Dennys por los consejos y el trabajo en
conjunto (rsync) a la hora de hacer parte de nuestras tesis.
A los nerds (en el mejor de los sentidos) Sergio y Pepe por enseñarme lo básico de Linux a la
hora de enfrentarme en alguna que otra situación.
A Alain Garófalo por sus acertadas recomendaciones a mi tesis y por ser el “gurú” en cuanto a
los procedimientos a realizar en la práctica.
A mis tíos y abuelos ya que sin ellos no me habría sido posible estar donde estoy ahora. También
por su constante preocupación por mis progresos tanto en mi tesis como en mi vida como
estudiante.
A todas las demás personas que no mencioné por mi mala memoria pero que de alguna forma
u otra contribuyeron con sus ideas.
A todos…..Gracias!!!!

DECLARACIÓN DE AUTORÍA
Autor:
El presente trabajo ha sido realizado conforme a las condiciones exigidas en las orientaciones
sobre la estructura del Trabajo de Diploma 2017. El mismo fue conformado en su totalidad por
el autor presentado en la declaración, el cual avala su originalidad y declara que no ha sido
publicado para obtener otros grados o títulos. Se autoriza la utilización del Trabajo de Diploma
con fines educativos o informativos por el Departamento de Telecomunicaciones y Telemática
de la Universidad Tecnológica de La Habana.
_____________________
Firma del autor
CERTIFICACIÓN
Certificamos que el presente trabajo fue desarrollado por ______________bajo nuestra
supervisión.
______________________ _________________________
MSc. Lilia Rosa García Perellada Dr. Alain A. Garófalo Hernández

RESUMEN
Los métodos para diseñar Sistemas de Almacenamiento para Centros de Datos existentes, en la
mayoría de los casos, no plantean un estudio previo de las condiciones del centro ni los
requerimientos técnicos que se deben cumplir de acuerdo a los tipos de servicio y tráfico que
necesitan las empresas. Solo ofrecen los pasos a seguir por las instituciones para adoptar ciertas
tecnologías de Almacenamiento con determinadas características que no necesariamente son
las que necesitan las empresas.
Por tanto, en el presente trabajo se confecciona un método para diseñar Sistemas de
Almacenamientos para Nubes Privadas con soporte para Infraestructura como Servicio para
pequeñas y medianas empresas partiendo de las necesidades y restricciones de las Tecnologías
de la Información y las Comunicaciones de cada una. Se obtuvo un método que ofrece
herramientas al diseñador a la hora de implementar estos sistemas y además es capaz de
adaptarse a los requerimientos específicos que demandan las aplicaciones de un Centro de
Datos bajo el paradigma de la Computación en la Nube con capacidad para IaaS, así como DSaaS.
El método obtenido fue validado mediante su implementación en un centro universitario
“Universidad Tecnológica de La Habana” obteniéndose resultados satisfactorios.

ABSTRACT
Methods for designing storage systems for existing data centers, in most cases, do not pose a
previous study of the conditions of the center nor the technical requirements that must be
met according to the types of service and traffic that the business need. Just provide the steps
for the institutions to adopt certain storage technologies with certain characteristics that are
not necessarily those businesses need.
Therefore, in the present investigation a method was created to design Private Cloud Storage
Systems with support for Infrastructure as a Service for small and medium enterprises based on
the needs and restrictions of the Information Technology and Communications of each one.
Was obtained a method that offers tools to the designer when it comes to implementing these
systems and is also able to adapt to the specific requirements demanded by the applications of
a Data Center under the paradigm of Cloud Computing with IaaS capacity and DSaaS capacity.
The method obtained was validated through its implementation in a university center
"Universidad Tecnológica de La Habana" obtaining successfully results.

INDICE
PORTADA................................................................................................................................. I
FRASE..................................................................................................................................... III
DEDICATORIA ........................................................................................................................IV
AGRADECIMIENTOS ...............................................................................................................V
DECLARACIÓN DE AUTORÍA..................................................................................................VI
RESUMEN .............................................................................................................................VII
ABSTRACT............................................................................................................................VIII
INDICE DE FIGURAS.............................................................................................................. XII
INDICE DE TABLAS............................................................................................................... XIII
INTRODUCCIÓN...................................................................................................................... 1
Capítulo 1: “Procedimientos de diseño de sistemas de almacenamiento. Elementos
considerados relevantes en el proceso de diseño.”.............................................................. 4
1.1. Introducción.................................................................................................................. 4
1.2. Filosofía de diseño top-down. Aplicación al diseño de sistemas de almacenamiento.... 4
1.3. Evaluación de los métodos de diseños de sistemas de almacenamiento para centros de
datos 7
1.4. Pruebas para identificar de los requerimientos impuestos por las aplicaciones y
servicios a soportar................................................................................................................ 13
1.5. Requerimientos No Funcionales identificados en el diseño de sistemas de
almacenamiento .................................................................................................................... 14
1.6. Modelos y Arquitecturas de Referencias para Sistemas de Almacenamiento.............. 18
1.6.1 Comparación entre los modelos de referencias y la NP................................... 20
1.6.2 Requerimientos funcionales a cumplir por el SA............................................. 22
1.7. Sistemas de Almacenamiento en la actualidad............................................................ 23
1.7.1 DAS, NAS y SAN ............................................................................................... 23
1.7.2 Sistemas basados en Objetos, Bloques y Ficheros............................................ 27
1.7.3 Aspectos para la selección de un sistema NAS o SAN ..................................... 31
1.7.4 Tipos de Infraestructuras más empleadas en SA.............................................. 33
1.7.5 Comparación entre las principales soluciones SLCA para SA........................ 36
1.7.6 Conclusiones parciales ...................................................................................... 40
1.8. Tipos de Discos para SA [25]........................................................................................ 41
1.8.1 Serial ATA (SATA).................................................................................................. 42
1.8.2 SAS........................................................................................................................... 42
1.8.3 Nearline SAS (NL-SAS).......................................................................................... 42
1.8.4 Canal de Fibra......................................................................................................... 43
1.8.5 Discos de Estado Sólido........................................................................................... 43
1.8.6 Discos Híbridos........................................................................................................ 44

1.9. Pruebas para caracterizar y evaluar sistemas de almacenamiento..................... 44
1.10. DSaaS. Principales soluciones SLCA.................................................................. 47
1.11. Sistema de Salvas. Principales soluciones SLCA............................................... 48
1.12. Conclusiones.......................................................................................................... 49
Capítulo 2: “Método de diseño de sistemas de almacenamiento para Nubes Privadas con
soporte para IaaS para pequeñas y medianas empresas”.................................................. 50
2.1. Introducción.................................................................................................................. 50
2.2. Presentación del método de diseño ............................................................................. 50
2.3. Regulaciones y/o políticas a cumplir por el sistema de almacenamiento................ 51
2.4. Requerimientos de las aplicaciones y/o servicios a soportar por el sistema de
almacenamiento................................................................................................................... 52
2.4.1 Datos Generales....................................................................................................... 52
2.4.2 Requerimiento de Utilización:................................................................................. 54
2.4.3 Dimensionamiento de las MV:................................................................................ 56
2.4.4 Requerimiento de Capacidades para ofrecer IaaS................................................. 57
2.5. Requerimientos no funcionales del sistema de almacenamiento ......................... 57
2.6. Caracterización del SA inicial (Opcional).............................................................. 59
2.7. Definición del SA a desplegar en la NP .................................................................. 60
2.8. Diseñar tomando en cuenta las restricciones del SA definido.............................. 61
2.8.1 Diseño Lógico .......................................................................................................... 61
2.8.2 Diseño Físico ........................................................................................................... 64
2.10. Pruebas para caracterizar y evaluar el sistema de almacenamiento .................... 67
2.11. Identificación del sistema de salvas..................................................................... 76
2.12. Conclusiones.......................................................................................................... 77
Capítulo 3: “Validación del método de diseño de Sistemas de Almacenamiento para Centros de
Datos”................................................................................................................................... 78
3.1. Introducción.................................................................................................................. 78
3.2. Regulaciones y/o política a cumplir por el SA........................................................... 78
3.3. Requerimientos de las aplicaciones ............................................................................ 81
3.3.1 Datos Generales....................................................................................................... 81
3.3.2 Requerimiento de Utilización:................................................................................. 82
3.3.3 Dimensionamiento de las MV:................................................................................ 83
3.3.4 Requerimiento de Capacidades para ofrecer IaaS................................................. 83
3.4. Requerimientos no funcionales del SA....................................................................... 83
3.5. Caracterización del SA inicial..................................................................................... 86
3.6. Definición del SA a desplegar...................................................................................... 86
3.7. Diseño Lógico................................................................................................................ 86
3.8. Diseño Físico ................................................................................................................. 89
3.9. Resultados de las Pruebas al SA ................................................................................. 91
3.10. Conclusiones ............................................................................................................... 95
CONCLUSIONES.................................................................................................................... 96
RECOMENDACIONES............................................................................................................ 97

REFERENCIAS BIBLIOGRAFICAS............................................................................................ 98
ANEXOS...............................................................................................................................105
Anexo A. Comparativa de los métodos de diseños de sistemas de almacenamiento para
centros de datos ................................................................................................................. 105
Anexo B. Modelo de Referencia de la Nube Privada. ................................................... 110
Anexo C. Conceptos básicos de los sistemas de ficheros distribuidos. [40].................. 111
Anexo D. Análisis de las soluciones SLCA más destacadas para SA. .......................... 122
Anexo E. RNF para el diseño del SA............................................................................... 138
Anexo F. Estructura para las pruebas [38]..................................................................... 145
Anexo G. Pruebas de utilización de las aplicaciones...................................................... 146
Anexo H. Útiles tomados del libro Top-Down de Cisco................................................. 151
Anexo I. Características del Almacenamiento Definido por Software (SDS).............. 152
Anexo J. Características principales de NAS y SAN ..................................................... 154
Anexo K. RF de las soluciones para ofrecer DSaaS....................................................... 156
Anexo L. RF de las soluciones para ofrecer Salvas........................................................ 157
Anexo M. RF de Ceph y GlusterFS. ................................................................................ 158
Anexo N. Ejemplos de diseños lógicos............................................................................. 160
Anexo Ñ. Áreas de la Gestión........................................................................................... 162
Anexo O. Guía de despliegue de Ceph en el CD CUJAE. ............................................. 163

INDICE DE FIGURAS
Figura 1 . Ciclo de vida del diseño e implementación de Redes de Áreas Locales (LAN)
[1]................................................................................................................................................ 4
Figura 2 Referencias consultadas en la evaluación de los métodos de diseño..................... 7
Figura 3 Cuadrante Mágico de Gartner Principales Proveedores de Nube e IaaS............ 8
Figura 4 Cuadrante Mágico de Gartner Proveedores de Soluciones de Almacenamiento 8
Figura 5 Principales proveedores de hardware para SA ...................................................... 9
Figura 6 Modelo de Referencia de la SNIA.......................................................................... 18
Figura 7 Modelo de Referencia de la UIT ............................................................................ 18
Figura 8 Modelo de Referencia de la Nube Privada............................................................ 18
Figura 9 Esquema del Sistema DAS...................................................................................... 24
Figura 10 Esquema del Sistema NAS.................................................................................... 25
Figura 11 Esquema del Sistema SAN.................................................................................... 26
Figura 12 Esquema del Almacenamiento de Objetos.......................................................... 27
Figura 13 Esquema del Almacenamiento de Bloques.......................................................... 29
Figura 14 Esquema del Almacenamiento de Ficheros ........................................................ 30
Figura 15 Ejemplo de Red Convergente............................................................................... 34
Figura 16 Resumen elección del SA ...................................................................................... 40
Figura 17 Método de Diseño para SA propuesto................................................................. 50
Figura 18 Procedimiento para la selección del SA............................................................... 60
Figura 19 Diseño Lógico......................................................................................................... 62
Figura 20 Diseño Físico .......................................................................................................... 65
Figura 21 Procedimiento para identificar el sistema de salvas .......................................... 76
Figura 22 Diseño Lógico del SA Ceph .................................................................................. 88
Figura 23 Diseño Físico del SA Ceph.................................................................................... 91
Figura 24 Throughput e IOPS de lectura y escritura de los discos duros......................... 92
Figura 25 Throughput e IOPS de lectura y escritura del clúster Ceph............................. 92
Figura 26 Latencias de los Discos empleados en el SA........................................................ 93
Figura 27 Latencias del SA en clúster................................................................................... 94

INDICE DE TABLAS
Tabla 1 Referencias consultadas en la evaluación de los métodos de diseño. ..................... 9
Tabla 2 Resultados del análisis de la Fase I.......................................................................... 10
Tabla 3 Resultados del análisis de la Fase II........................................................................ 10
Tabla 4 Resultados del análisis de la Fase III ...................................................................... 11
Tabla 5 Resultados del análisis de la Fase IV....................................................................... 12
Tabla 6 Resultados en la caracterización de aplicaciones................................................... 14
Tabla 7 Estudio de los RNF a considerar a la hora de desplegar un SA ........................... 14
Tabla 8 RNF a cumplir por el SA de forma general............................................................ 22
Tabla 9 Aplicaciones de SAN o NAS..................................................................................... 31
Tabla 10 Elección de SAN o NAS en cuanto a los RNF....................................................... 31
Tabla 11 Tabla Resumen de la comparación entre los principales DFS. .......................... 39
Tabla 12 Características de las interfaces de almacenamiento actuales............................ 41
Tabla 13 Propuesta de pruebas para evaluar SA. ............................................................... 45
Tabla 14 Identificación de aplicaciones de usuarios y de servicios .................................... 53
Tabla 15 Identificación de los servicios IaaS o DSaaS ........................................................ 53
Tabla 16 Métricas de utilización de recursos de almacenamiento y red por servicio ...... 54
Tabla 17 Métricas de capacidad por servicio a desplegar. ................................................. 56
Tabla 18 Métricas de capacidad por servicio a brindar en la IaaS.................................... 57
Tabla 19 Capacidades por subsistema.................................................................................. 64
Tabla 20 Herramientas para realizar las pruebas al SA..................................................... 68
Tabla 21 Datos Generales servicio Navegación de Internet................................................ 81
Tabla 22 Identificación de los servicios IaaS o DSaaS ........................................................ 81
Tabla 23 Métricas de utilización de recursos de almacenamiento y red por servicio ...... 82
Tabla 24 Métricas de capacidad por servicio a desplegar. ................................................. 83
Tabla 25 Resultados de Capacidades Totales a Soportar por el SA .................................. 88
Tabla 26 Resumen del Hardware empleado en el SA.......................................................... 90
Tabla 27 Throughput de la Red Cliente Interfaz 1.............................................................. 93
Tabla 28 Throughput de la Red Cliente Interfaz 2.............................................................. 93
Tabla 29 Throughput de la Red Clúster............................................................................... 93
Tabla 30 Tabla de Resultados Prueba de Estrés.................................................................. 94
Tabla 31 Tabla de Resultados Prueba de Utilización.......................................................... 95
Tabla 32 RNF del SA............................................................................................................ 138

Introducción
1
INTRODUCCIÓN
Los Sistemas de Almacenamiento (SA) son parte imprescindible hoy en día de los Centros de
Datos (CD) ya que son en ellos donde es alojada la información, los servicios y las aplicaciones
que constituyen la razón de ser de las empresas. La adopción de estos sistemas ha traído
consigo innumerables beneficios tanto para los proveedores como para los clientes. Ventajas
como la gestión centralizada de la información, compartición de datos de forma inmediata,
seguridad y alta disponibilidad de datos y la fácil escalabilidad que proveen estos sistemas son
solo un ejemplo por lo cual las empresas los adoptan.
Sin embargo, dado el estudio realizado en [11] [9] [10] [12] [13] [14] [15] [16] [17] [18] [19] [20]
[21] [22] se pudo detectar que los métodos para diseñar SA para CD existentes, en la mayoría
de los casos, no plantean un estudio previo de las condiciones del centro ni los requerimientos
técnicos que se deben cumplir de acuerdo a los tipos de servicio y tráfico que necesitan las
empresas. Solo ofrecen los pasos a seguir por las instituciones para adoptar tecnologías de
almacenamiento con determinadas características que no necesariamente son las que
necesitan las empresas. También no fue identificado un documento oficial con directivas para
la adopción de un Sistema u otro y las organizaciones de estandarización investigadas [15] [16]
[17] solo ofrecen algunas recomendaciones a la hora del despliegue, pero no indican como
elegirlos. Otro aspecto detectado es que las empresas adoptan una u otra tecnología de
almacenamiento sin la previa caracterización de los servicios u aplicaciones que en este van a
operar. En suma, no fue detectado un modelo de pruebas oficial para evaluar SA, cada empresa
aplica uno personalizado.
El no tener un procedimiento para el diseño de estos sistemas puede traer numerosos
problemas que radican principalmente en la mala elección entre un sistema u otro. A su vez, un
mal dimensionamiento y la no caracterización de las aplicaciones que sobre él van a desplegarse
pueden provocar que los servicios no funcionen de manera adecuada a la esperada provocando
demoras innecesarias a la hora de obtener la información, mala utilización de los recursos del
sistema que se puede traducir como sobre o sub-dimensionamiento e inconformidad por parte
de los usuarios finales. Lo anterior trae consigo gastos innecesarios tratando de mejorar el
sistema o gastos a la hora de comprar uno que no se corresponde con los requerimientos del
usuario.
Dada la situación problemática anterior el problema a resolver es: la insuficiente articulación
entre las estrategias para el despliegue de los SA en CD privados bajo el paradigma de la
Computación en la Nube (CN) teniendo en cuenta los requerimientos que las empresas e
instituciones realmente necesitan. Por lo que la investigación tuvo como objeto de estudio a los

Introducción
2
SA y un campo de acción que abarcó los procedimientos de diseño de SA para Nubes Privadas
(NP) con soporte para brindar Infraestructura como Servicio (IaaS1).
Por tanto, el objetivo general de este trabajo fue: obtener un procedimiento para diseñar SA
para NP con soporte para IaaS partiendo de las necesidades y restricciones de cada lugar donde
se implemente.
Las tareas trazadas para darle cumplimiento a los objetivos fueron:
 Buscar y revisar bibliografía actualizada de métodos de diseño de SA para CD privados,
manuales de diseño y casos de estudio de SA para NP con soporte para brindar IaaS,
ofrecidos por los principales proveedores, tanto de soluciones propietarias como de
Software Libre y Código Abierto (SLCA).
 Comparar los principales modelos de referencia de SA proporcionados por la Unión
Internacional de Telecomunicaciones (UIT), la Asociación Industrial de Redes de
Almacenamiento (SNIA2) y la Arquitectura de Referencia Funcional (ARF) de NP.
 Seleccionar el modelo de referencia para el SA a emplear en el procedimiento a obtener.
 Estudiar las cuatro fases de diseño definidas por el método de diseño de redes
empresariales top-down.
 Confeccionar el procedimiento.
 Validar el procedimiento obtenido.
Métodos de investigación:
- Método sistémico. Su utilización permitirá determinar y definir las fases del método de
diseño a realizar y a concebir y sus dependencias
- Métodos teóricos. Mediante una revisión bibliográfica se podrá conocer las
características de cada método existente.
- Métodos empíricos se utilizaron para el análisis documental durante la revisión
bibliográfica, el estudio de las arquitecturas de referencia definidas para los SA, los
manuales de diseño y casos de estudio
- Métodos analíticos. Para generalizar y confeccionar una posible metodología.
Método de la observación científica de conjunto con el método experimental: sirvió para
garantizar la validez de los resultados parciales, finales y del método desarrollado
El trabajo de diploma se dividió en introducción, tres capítulos, conclusiones, recomendaciones,
bibliografía y anexos. Los capítulos fueron organizados como se muestra a continuación:
1
Siglas correspondientes al término en Inglés: Infrastructure as a Service.
2
Siglas correspondientes al término en Inglés: Storage Networking Industry Association.

Introducción
3
Capítulo 1: “Procedimientos de diseño de sistemas de almacenamiento. Elementos considerados
relevantes en el proceso de diseño.” En este capítulo se realiza una investigación acerca de los
procedimientos existentes actualmente para el diseño de SA y se muestra el estado del arte de
algunos de los elementos a tener en cuenta a la hora de su diseño.
Capítulo 2: “Método de diseño de sistemas de almacenamiento para Nubes Privadas con soporte
para IaaS para pequeñas y medianas empresas”. En este capítulo se confecciona el método de
diseño a partir de todo el análisis realizado en el primer capítulo detallando los procedimientos
a realizar en cada fase diseñada.
Capítulo 3: “Validación del método de diseño de Sistemas de Almacenamiento para Centros de
Datos”. En este capítulo se pone a prueba el método confeccionado mediante su aplicación en
un centro de datos.

considerados relevantes en el proceso de diseño.”
4
Capítulo 1: “Procedimientos de diseño de sistemas de almacenamiento. Elementos considerados
relevantes en el proceso de diseño.”
1.1. Introducción
El autor de la presente investigación no identificó un procedimiento de diseño de SA para CD
que sea referencia para proveedores y diseñadores de infraestructura. El estudio de las buenas
prácticas, guías de despliegue y recomendaciones técnicas de proveedores de soluciones de NP
y de soluciones de SA, permitió entonces identificar los criterios de diseño comunes en el
ámbito, así como las principales tendencias en la proyección de SA y sus principales tecnologías.
Un análisis crítico acerca de cómo los procedimientos examinados toman en cuenta una filosofía
de diseño top-down o botton-up, sirvió de base para abordar elementos claves que deben estar
presentes en la proyección de SA como sus Requerimientos no Funcionales (RNF) y las ARF
existentes.
1.2. Filosofía de diseño top-down. Aplicación al diseño de sistemas de almacenamiento
El principal aporte de la filosofía top-down reside en contribuir a que el diseño creado satisfaga
realmente los objetivos y requerimientos técnicos perseguidos por la entidad cliente. Este
plantea cuatro fases, definidas en un proceso iterativo y cíclico como se muestra en la Figura 1.
La primera fase abarca el análisis de los objetivos, metas, requerimientos técnicos y
restricciones que presenta el cliente en el proyecto de diseño, junto a la caracterización del
sistema inicial, de existir. Las fases segunda y tercera desarrollan el diseño lógico y físico
respectivamente, en las que se deben brindar directrices y guías para el diseño, así como
criterios para la selección de las diferentes tecnologías y elementos físicos. La cuarta fase aborda
el proceso de pruebas para validar el diseño propuesto, su optimización y la documentación del
proceso de diseño [1].
También propone la implementación de un sistema que sea modular [1], para facilitar la
disponibilidad, adaptabilidad, flexibilidad y escalabilidad. Esta particularidad debe ser aplicada
en el diseño de los SA para lograr cumplir con los RNF a los que tributa.
Figura 1 . Ciclo de vida del diseño e implementación de Redes de Áreas Locales (LAN)
[1]

5
Realizando una analogía para el diseño de SA las fases de la filosofía top-down, a consideración
del autor, permitirá:
FASE I, análisis de los requerimientos:
 Definir los objetivos del negocio que persigue el cliente con el nuevo proyecto,
especificar las metas a cumplir para que este sea considerado exitoso, las consecuencias
del fracaso y las restricciones a tomar en cuenta durante el proceso del diseño. Todo lo
anterior influye directamente en el proceso de toma de decisiones lo que contribuye
desde un inicio, a la correcta elección de las tecnologías y productos, y si se identifican
concretamente la misión y la visión de la entidad, permitirá detectar las problemáticas
a resolver para alcanzar los resultados, hasta en la definición de las pruebas para validar
el éxito del proyecto [1].
 En caso de ser necesario, si ya existiese una infraestructura desplegada, determinar y
documentar el estado inicial del sistema, o sea, de su infraestructura, aplicaciones y
otros para poder identificar los principales problemas que atentan con las metas a
cumplir, identificar los elementos que pueden ser reutilizados en el nuevo diseño. Para
ello el autor considera que debe emplearse un proyecto de pruebas muy similares a las
empleadas para validar el diseño obtenido.
 Identificar de forma específica los servicios, las aplicaciones y/o los datos que soportará
el SA, y por quiénes será utilizado. Esto permite dimensionar y seleccionar las
tecnologías eficientemente.
 Identificar los RNF del SA. La correcta realización de este paso es necesaria a la hora de
la realización de las FASES II y III, ya que los RNF deben responder a los requerimientos
para alcanzar las metas del negocio con la QoS3 esperada y las restricciones existentes.
Para las organizaciones varios requerimientos técnicos pueden resultar importantes,
incluso con diferentes niveles de criticidad en función de la misión de la misma [2] [3].
FASE II, diseño lógico:
 Identificar los tipos de sistemas de almacenamiento a utilizar: Redes de Área de
Almacenamiento (SAN4), Almacenamiento Conectado a la Red (NAS5), DAS6, o híbrido,
según los RNF a cumplir.
 Dimensionar el SA.
 Identificar las características de los discos a emplear, así como las controladoras a utilizar
según los RNF a cumplir.
3
Siglas correspondientes al término en Inglés: Quality of Service
4
Siglas correspondientes al término en Inglés: Storage Area Network.
5
Siglas correspondientes al término en Inglés: Network Attached Storage.
6
Siglas correspondientes al término en Inglés: Direct Attached Storage

6
 Identificar las características de las tecnologías de interconexión de red [4], así como
los dispositivos a utilizar y elegir [5]–[8] óptimos para el diseño.
FASE III, diseño físico:
 Desarrollar el proceso de selección de la solución de SA que se acople a las
características de la empresa según los RNF a cumplir.
 Seleccionar las tecnologías de interconexión de red [4] [5]–[8] que respondan al diseño
de SA escogido.
 Seleccionar los tipos de discos a emplear según las características propias del SA.
FASE IV, probar, optimizar y documentar:
 Despliegue de un prototipo del diseño propuesto, o su modelación, con las
configuraciones, aplicaciones y requerimientos del mismo, para comprender el
comportamiento de la propuesta.
 Identificar las herramientas necesarias para las pruebas del SA así como las métricas
para conocer si el sistema responde de manera eficiente [9] [10] . Esto es aplicable a
estos sistemas, debido a que existen varios tipos de SA, los cuales no ofrecen las mismas
características ni están diseñados para los mismos ambientes, por lo que resulta
fundamental elaborar pruebas diferentes para cada uno con el fin de evaluar sus
parámetros de rendimiento en el ambiente particular del CD de la empresa.
 Cada prueba a ejecutar debe ser descrita con las siguientes especificaciones: objetivos
y criterios de aceptación, tipo de prueba, recursos necesarios, descripción de los pasos
de implementación, y su planificación en tiempo. Los objetivos deben ser claramente
definidos y deben responder a los metas del negocio y a los requerimientos técnicos
planteados por el cliente para poder evaluar el éxito del proyecto.
 En base a los resultados de las pruebas, pueden ser aplicadas técnicas de optimización.
La optimización permite hacer un uso eficiente de los recursos sin degradar el
rendimiento del sistema, así como el tratamiento de manera diferenciada a las
diferentes aplicaciones en función del nivel de importancia para la entidad.
 Finalmente se debe haber obtenido una propuesta de diseño basada en el análisis de los
objetivos del negocio y los requerimientos técnicos, que incluye componentes lógicos y
físicos comprobados y optimizados. La última etapa es escribir el documento del diseño.
Este debe contener las metas planteadas por el cliente, cómo fueron satisfechas, la
caracterización del escenario real, las aplicaciones necesarias y sus requerimientos, los
diseños lógico y físico, el presupuesto y los gastos asociados al proyecto, los planes de
implementación, las mediciones que indiquen el éxito del despliegue y cómo debe
evolucionar el diseño si surgen nuevos requerimientos.

7
1.3. Evaluación de los métodos de diseños de sistemas de almacenamiento para centros de
datos
En post de identificar estándares, métodos, procedimientos, guías y/o buenas prácticas para
diseñar SA se realizó una revisión bibliográfica que abarcó: publicaciones académicas
consistentes en artículos, ponencias, libros y tesis indexados en BD de alto rigor científico
técnico como Ieeexplore [11] , Springer [12], ACM7 [13] y otras fuentes; guías, estándares y
reportes de organismos de estandarización, proveedores de soluciones de NP y de soluciones
de hardware y software de SA tanto propietarias como SLCA. También se realizó un estudio de
los proveedores de hardware COTS8 para SA. La Figura 2 muestra las referencias consultadas
por categorías:
Resultados obtenidos en la búsqueda:
De las publicaciones Académicas se pudieron identificar tres correspondiente al tema en
cuestión, dos de ellas corresponden a los artículos presentados en el Evento Cittel9 por los
Ingenieros Dayron Alberus Padrón y Alejandro Santoyo González y un artículo del Gobierno de
Australia.
En cuanto a los organismos de estandarización sólo la SNIA10 fue la de mayor utilidad
pudiéndose encontrar numerosas recomendaciones en cuanto a buenas prácticas y aspectos a
considerar a la hora de desplegar un SA.
7
Siglas correspondientes al termino en inglés: Association for Computing Machinery
8
Siglas correspondientes al termino en inglés: Commercial off-the-shelf.
9
Siglas correspondientes a: “Congreso Internacional de Telemática y Telecomunicaciones”. CITTEL está dirigido
a especialistas, funcionarios y científicos de la comunidad nacional e internacional que estudian y ejecutan
actividades relacionadas con la solución de problemas en las ramas de la telemática, las telecomunicaciones y
disciplinas afines.
10
Siglas correspondientes al término en inglés: Storage Networking Industry Association. La (SNIA) es una
organización no lucrativa compuesta de las compañías del miembro que atraviesan la tecnología de la
información. SNIA tiene como misión liderar la industria del almacenamiento en el desarrollo y la promoción de
arquitecturas, estándares y servicios educativos que facilitan la gestión, el movimiento y la seguridad de la
información.
3
1
44
2
2
Bibliografía consultada
Publicaciones Académicas
Organismos de Estandarización
Proveedores de Nube, Hardware y
Software privados
Proveedores de SLCA de SA
Gestores de Nubes SLCA
Proveedores Hardawre COTS
Figura 2 Referencias consultadas en la evaluación de los métodos de diseño

8
Por su parte Proveedores de Nube, Hardware y Software privados se pudieron identificar los
más importantes como Microsoft, IBM, Dell EMC y Net App que constituye hoy en día líderes
en estas tecnologías a nivel mundial según el cuadrante mágico de Gartner (Figuras 3 y 4) y es
importante conocer las recomendaciones que estos brindan a los clientes a la hora de
implementar sus SA.
De los Proveedores de SLCA de SA se escogió una muestra de aquellos que tuvieran interés en
la comunidad científica y para ello se realizó una búsqueda en la IEEE y se escogió como
referencia a tres de ellos: Ceph (software que actualmente se encuentra con gran popularidad
en la comunidad Linux por poder brindar almacenamiento tanto en bloques, objetos y ficheros
por lo que puede ser utilizado tanto para el despliegue de una SAN o una NAS); GlusterFS
(software especialmente para almacenamiento como ficheros por lo que es ideal para una NAS);
FreeNAS (otro software muy utilizado especializado en sistemas NAS); Openfiler (es un software
que permite brindar tanto almacenamiento en bloques para una SAN como almacenamiento
en ficheros para una NAS). El objetivo de este análisis radicó en identificar si estos proveedores
proponían una guía genérica para el despliegue de los mismos teniendo en cuenta las fases del
top-down.
De forma similar se analizaron gestores de Nube también SLCA en busca de procedimientos o
buenas prácticas a la hora de desplegar el almacenamiento que constituye uno de los bloques
funcionales de la Nube. De ellos se tomó como muestra a dos de ellos y que tienen gran
utilización en la comunidad Open Nebula y OpenStack, aunque vale destacar que también
presentan versiones pago.
Figura 4 Cuadrante Mágico de Gartner
Proveedores de Soluciones de
Almacenamiento
Figura 3 Cuadrante Mágico de Gartner Principales
Proveedores de Nube e IaaS

9
Por último, se investigó acerca de los principales proveedores de hardware COTS realizando un
análisis de los principales proveedores de hardware y servidores a nivel mundial. En la
investigación se tuvo en cuenta a HP, Dell EMC, IBM, CISCO, Huawei, Inspur, pero solo se pudo
identificar como proveedores COTS a Huawei e Inspur. (Figura 5)
En la Tabla 1 se muestran los nombres de las referencias consultadas y el número de la
referencia en sí y en la Anexo A se muestra la comparativa completa entre los métodos de
diseños y/o buenas prácticas para el despliegue de SA identificadas y cómo contemplan las fases
planteadas por la filosofía top-down.
Tabla 1 Referencias consultadas en la evaluación de los métodos de diseño.
No. Nombre Referencia
1 Cisco [14]
2 Intel [9]
3 IBM [10]
4 NetApp-Vmware [15]
5 Dell EMC-Microsoft [16]
6 Brocade [17]
7 SNIA [18] [19] [20]
8 Arista [21]
9 Gobierno de Australia [22]
10 Artículo en Cittel Ing. Dayron Alberus Padrón [23]
11 Artículo en Cittel Ing. Santoyo [24]
12 Corporación Microsoft [25]
13 SLCA SA Ceph [26]
14 SLCA SA GlusterFS [27]
15 SLCA SA FreeNAS [28]
16 SLCA SA Openfiler [29]
Figura 5 Principales proveedores de hardware
para SA

10
17 SLCA Gestor de Nube Open Nebula [30]
18 SLCA Gestor de Nube Open Stack [31]
19 Proveedor de Hardware COTS Inspur [32]
20 Proveedor de Hardware COTS Huawei [33]
Análisis de los Resultados de la Investigación:
FASE I “Análisis de los requerimientos”:
Tabla 2 Resultados del análisis de la Fase I
Aspecto Comentario
% de
cumpl
imien
to
Estudio de la misión,
visión, la estructura
organizacional de la
entidad cliente y sus
características
Este aspecto es uno de los que menos cumplimiento
tiene según los resultados ya que no se pudo verificar
su aplicación exceptuando a 7,10 y 11 los cuales si
abogan por el estudio de este aspecto.
15%
Definición de los
objetivos del negocio
En cuanto a este indicador también se aprecia poco
interés en él solo 2,7,10 y 11 abogan por su realización.
20%
Caracterización del
estado inicial del
sistema
(infraestructura y
servicios)
Respecto a este parámetro de gran importancia se
pudo apreciar que tampoco se tiene mucho en cuenta,
solo es propuesto por 1,2,6,7,8,10 y la mayoría asume
que la implementación se realizará en escenarios
donde no existe aún ninguna infraestructura.
30%
Definición de
restricciones
En este caso si se aprecia un gran cumplimiento por
gran parte de los investigados dada la importancia de
establecer dichas restricciones las cuales abarcaron
tanto restricciones de hardware, software, así como
área de instalación.
75%
Definición de los
servicios y/o
aplicaciones que
utilizarán el SA, y su
caracterización
Aquí solo 6 y 7 proponen que se deben caracterizar los
servicios y/o aplicaciones que utilizaran el SA, pero no
ofrecen ninguna herramienta para hacerlo. Por su parte
10 y 11 lo proponen y ofrecen una pequeña
herramienta para hacerlo, pero muy pobre por lo que
debe ser mejorada.
20%
Definición de los RNF
a soportar por el SA.
Aquí 1 y 7 proponen que se deben conocer los RNF que
debe cumplir el SA, no propone ni presenta ningunos.
Por su parte 10 y 11 si proponen RNF definidos a
cumplir por un SA. También 13,14,15 y 16 que
corresponden con los softwares para implementar el SA
elegidos definen los RNF que ellos satisfacen.
35%
División de fases
La división de fases es cumplida por todos excepto por
los Softwares y los Proveedores COTS en los cuales no
se definen fases de diseño.
60%
FASE II “Diseño lógico”:
Tabla 3 Resultados del análisis de la Fase II

11
Aspecto Comentario
% de
cumpl
imien
to
Estudio del tipo de SA
a utilizar según los
RNF
En este aspecto la mayoría aboga por un sistema u otro
según variados aspectos los cuales son diferentes en
uno u otro. Es necesario una investigación para definir
de manera precisa cuando SAN o NAS. Están exentos de
este análisis los softwares y los proveedores COTS ya
que no tiene sentido el estudio de este aspecto en ellos
58%
Identificación de las
características de los
discos a emplear, así
como las
controladoras a
utilizar según los RNF
a cumplir.
Este aspecto es muy desarrollado por casi todos ya que
la mayoría propone las características que deben tener
los discos a utilizar y realizan una breve explicación de
lo que puede ofrecer uno u otro tipo de disco.
55%
Dimensionamiento
del SA teniendo en
cuenta las
características de los
servicios y
aplicaciones que se
demanden.
Muy poco desarrollado, solo es tomado en cuenta y
brindan una pequeña herramienta para su realización
por 10 y 11. Por su parte 18 ofrece una breve
explicación del porqué es necesario una planificación
de las capacidades y otros aspectos que tributan al
dimensionamiento.
15%
Identificación de las
características de las
tecnologías de
interconexión de red,
así como los
dispositivos a utilizar.
La mayoría logra identificar las tecnologías de
interconexión y las topologías necesarias para
desplegar su sistema e incluso ofrecen algunos
ejemplos de diferentes despliegues con distintas
configuraciones.
75%
División de fases
En la mayoría de los casos no existe diferencia entre el
diseño lógico y el físico, de hecho, la mayoría lo hace de
forma simultánea. Solo se pudo apreciar una
diferenciación de fases en 10, 11 y 12.
15%
FASE III “Diseño físico”:
Tabla 4 Resultados del análisis de la Fase III
Aspecto Comentario
% de
cumpl
imien
to
Selección de la
solución (SAN/NAS)
del SA que se acople a
las características de
la empresa según los
RNF a cumplir.
En este aspecto solo 10 y 11 seleccionan de acorde a
los RNF y explican el porqué de su selección. En los
demás no queda bien fundamentada el porqué de una
u otra o el diseño corresponde a una u otra tecnología
en específico. Quedan exentos de este análisis los
proveedores COTS.
12%

12
Elección del software
correspondiente a
una solución u otra.
La mayoría elige un software que se corresponde con la
solución elegida, en la mayoría de los casos softwares
propietarios dada la naturaleza de la revisión
bibliográfica. En los casos 10 y 11 se muestran
alternativas o comparativas entre distintas soluciones y
por qué se decide por una u otra.
50%
Propuesta para la
selección del
Hardware del SA.
En ningún caso se realizan propuesta del hardware para
el SA. En el caso de los proveedores privados estos
recomiendan el uso de su propio hardware y no
muestran alternativa para ello.
0%
Selección de los tipos
de discos a utilizar en
el sistema de
almacenamiento
según los RNF.
En 2,3 y 12 se muestran en sí modelos de discos y se
justifica la selección de los mismos. En los demás casos
solo se enfocan en las características que deben
cumplir los discos, pero no concretan una selección.
15%
Selección de las
tecnologías de
interconexión de red
que respondan al
diseño de SA
escogido.
La gran mayoría selecciona el dispositivo adecuado
para el buen funcionamiento de su SA. En gran parte la
selección se centra en los propios dispositivos de la
compañía que propone la solución. Los proveedores de
SLCA y los COTS no desarrollan esta fase.
35%
División de fases
En todos se observa una división entre esta fase y la
siguiente. En los proveedores de SLCA y los COTS no se
observa.
60%
FASE IV “Probar, optimizar y documentar”:
Tabla 5 Resultados del análisis de la Fase IV
Aspecto Comentario
% de
cumpl
imien
to
Despliegue de un
prototipo del diseño
propuesto, o su
modelación, con las
configuraciones,
aplicaciones y
requerimientos del
mismo, para
comprender el
comportamiento de la
propuesta.
La gran mayoría despliega un modelo con los
principales parámetros de configuración del sistema en
sí. Se observa con mayor énfasis y argumentación en
los SLCA investigados. En los COTS no se aplica ya que
ellos solo proveen el hardware y no se identificó
ninguna sugerencia de despliegue y configuración.
85%
Identificar las
herramientas
necesarias para las
pruebas al SA.
Pocos son los que proponen herramientas para testear
el SA. Solo 5,6,10,11,14 y 15 proponen nombres de
herramientas y los parámetros que estas miden. En los
demás casos, o no se proponen o usan herramientas
propias de la solución.
30%

13
Identificar las
métricas para conocer
si el sistema responde
de manera eficiente.
Algunos mencionan algunas métricas de interés como
IOPS11, throughput, uso de red, pero no establecen
umbrales de buen comportamiento de las mismas
como se puede ver en 1,3,4,5,7. Por su parte en 10 y 11
se pueden ver con mayor claridad las métricas
correspondientes a un SA.
35%
Ejecución de las
distintas pruebas al
SA.
La mayoría realizan pruebas, pero solo exponen los
resultados, no exponen las características de estas
pruebas ni el escenario donde se realizaron ni las
herramientas que utilizaron. Solo se pudo ver con
claridad en 10 y 11 que proponen un modelo de
pruebas bien definido y las herramientas para
realizarlas.
50%
Optimización.
Este se pude ver con mayor cumplimiento y claridad en
los proveedores de SLCA para SA en los cuales
proponen una vez instalado el sistema formas para
optimizarlos con la documentación correspondiente,
pero requiere de gran conocimiento por parte del que
lo va a realizar. Por otro lado los otros solo proponen la
acción de optimizar pero no dicen cómo.
50%
Conclusiones Generales:
En base a los resultados obtenidos de la investigación se hace necesario un método de diseño
que contemple todos los aspectos anteriores y que pueda resolver las deficiencias detectadas
en la bibliografía consultada y que sirva de guía para el correcto despliegue de un SA.
1.4. Pruebas para identificar de los requerimientos impuestos por las aplicaciones y servicios
a soportar
Para tener un correcto conocimiento de los requerimientos necesarios para el buen
funcionamiento de las aplicaciones de la nube es necesario conocer y medir las principales
métricas en las cuáles ellas tienen un impacto. Por su parte la filosofía de diseño de redes top-
down considera como parte de su primera fase la identificación y caracterización de las
aplicaciones que soportará el sistema a diseñar, tantos las existentes como las que se
incorporarán a corto y largo plazo [1]. Plantea que el diseño debe ser partir de las aplicaciones
ya que estas son las razones de ser de la red, y que por tanto la infraestructura subyacente debe
tributar a sus requerimientos [1] [34] .
Conocer a ciencia cierta dichas métricas y sus valores óptimos resulta complicado ya que en la
mayoría de los casos el desarrollador de dichas aplicaciones propone escenarios genéricos y el
resultado de la monitorización de algunos parámetros que en ocasiones no corresponden con
los requerimientos específicos del cliente [35] [36].
11
Siglas correspondientes al término en Inglés: Input/Output Operations per Second

14
A pesar de ello resulta importante conocer las métricas a la hora de caracterizar una aplicación.
En el estudio realizado en [35] [36] [37] [38] [3] [23] [1] [14] [9] [10] [15] [16] [17] [18] [19] [20]
[21] [22] [24] se pudo comprobar lo siguiente:
Tabla 6 Resultados en la caracterización de aplicaciones
Aspectos Referencias
Caracterizan las aplicaciones con sus métricas y ofrecen un
procedimiento para hacerlo.
[38] [1]
Indican que se deben caracterizan las aplicaciones, pero no lo
realizan ni ofrecen procedimientos o métricas.
[24] [23]
Exponen métricas que pueden ser de interés a la hora de
caracterizar las aplicaciones.
[35] [36] [37] [3]
Implementan el diseño de un SA sin caracterizar las
aplicaciones, ni indicarlo, ni ofrecer métricas ni
procedimientos.
[14] [9] [10] [15] [16] [17]
[18] [19] [20] [21] [22]
Como se puede observar se hace necesario la creación de una herramienta que permita la
caracterización de las aplicaciones con vista a su implementación sobre un SA por la importancia
que esto conlleva ya que de no hacerse podríamos caer en errores de sub o
sobredimensionamiento.
Por lo que para la creación de la herramienta que se expone en el Epígrafe 2.4 se tomó como
referencia principal a [38] ya que ofrece un procedimiento para caracterizar las aplicaciones,
una plantilla para plasmar la información , así como las herramientas necesarias para
obtenerlas. A [1] como modelo inicial a la hora de plasmar la información basado en la tabla
ofrecida en el ANEXO G y un listado de los posible tipos de aplicaciones. Por últimos a [35] [36]
[37] [38] [3] [1] para la extracción de las métricas necesarias tales que aplicaron directamente
a SA como la medición de los IOPS, Throughput de Red y Disco así como los aspectos de
Capacidad.
1.5. Requerimientos No Funcionales identificados en el diseño de sistemas de
almacenamiento
Existe una fuerte interrelación e interdependencia entre los RF y los RNF. Durante un proceso
de diseño basado en la filosofía top-down el diseñador debe esclarecer junto con el cliente los
RNF que este último desea en su diseño. En base a los RNF seleccionados por el cliente se eligen
los RF necesarios y en un momento posterior se selecciona el hardware y software necesario
que cumpla con los requerimientos técnicos preestablecidos. Además, el almacenamiento es
uno de los bloques funcionales de la nube privada por lo que éste hereda directamente sus RNF.
La Tabla 7 muestra un estudio de los RNF a considerar a la hora de desplegar un SA cuya
investigación abarca hasta el 2016 y según [3] son los más utilizados en la industria.
Tabla 7 Estudio de los RNF a considerar a la hora de desplegar un SA

15
RNF Descripción Referencias
Escalabilidad
Vertical
Indica la capacidad del sistema para incrementar la
capacidad del hardware y software existente añadiendo
recursos a estos.
[3] [39] [23]
[40]
Comentario
En este parámetro difiere un poco con la descripción empleada ya que en SA debe ser
enfocado en la capacidad de agregar dispositivos de almacenamiento al sistema. Además se
realizó un estudio a [41] [42] [43] [44] [45] [46] para comprobar si era factible el diseño
dejando espacio para la escalabilidad vertical. Los resultados alojaron que los proveedores
de Hardware diseñan sus equipos para un máximo de 5 años después de lo cual dejan de
dar soporte por lo que el autor propone el diseño del SA con 100% escalabilidad vertical, es
decir aprovechar el 100% de sus potencialidades desde un inicio ya que de no hacerlo en un
futuro se puede recaer en gastos superiores tratando de buscar repuestos a dicho sistema.
Escalabilidad
Horizontal
Indica la capacidad del Sistema de aumentar su capacidad
mediante la agregación de nuevas entidades de hardware
o software (nodos de procesamiento, almacenamiento),
de manera económicamente factible, manteniendo los
niveles de desempeño requeridos.
[3] [39] [23]
[40] [26]
[27] [28]
[29]
Comentario
Con respecto a esto el autor considera que el enfoque “entidades” no es bien aplicable al
diseño de SA, debería considerarse su enfoque con respecto a “nuevos nodos de
almacenamiento”. Por lo demás se está de acuerdo en que debe ser “de manera
económicamente factible, manteniendo los niveles de desempeño requeridos”.
Elasticidad
El grado al cual un sistema es capaz de adaptarse a los
cambios en las cargas de trabajo a través del
aprovisionamiento y desaprovisionamiento de recursos de
manera autonómica.
[3] [39] [40]
Comentario
En este aspecto el autor considera que no es aplicable a él, es decir que no presenta sentido
en el diseño de SA. Este requerimiento es más bien aplicable a los nodos de cómputo del
sistema no al SA.
Compatibilidad
La compatibilidad como atributo se refiere al soporte que
tiene la arquitectura para diferentes estándares,
tecnologías, y sus evoluciones con el propósito de ser
compatible con diferentes proveedores de hardware y
soluciones de software.
[3] [39] [40]
[26] [27]
[28] [29]
Comentario
Este RNF es muy importante ya que de él depende que el SA pueda ser implementado en
distintos tipos de SO y Hardware. El autor considera que debe ser modificado “tiene la
arquitectura” por “tiene el SA” ya que tendría un mejor enfoque en el diseño de SA.
Flexibilidad
La flexibilidad es la habilidad de añadir o eliminar
funcionalidades o características a los servicios existentes.
[3] [39] [40]
[26] [27]
[28] [29]
Comentario
El enfoque debería ser en cuanto a las potencialidades que tiene la solución de software del
SA para nuevas funcionales que permitan una mejor usabilidad. Por ejemplo: soporte para
pluggins o la facilidad de integración con herramientas de terceros.
Confiabilidad
Refleja las medidas de cómo operan los servicios sin fallas
bajo condiciones dadas durante un período de tiempo
determinado.
[3] [39] [23]
[40]

16
Comentario
El autor está de acuerdo con la definición, pero con la modificación de “cómo operan los
servicios” a “cómo opera el SA” para dar un mejor enfoque.
Recuperación
ante fallas
Es el grado en el que un servicio es capaz de rápidamente
volver a su estado normal de operación después de una
interrupción no planificada.
[3] [23] [40]
[26] [27]
[28] [29]
Comentario
Aquí el enfoque no es el correcto. Debería ser en vez de “el grado en el que un servicio” a
“la forma en que el SA”. Además, no queda claro que es una “interrupción” debería estar
enfocado a “una falla de naturaleza intencional o no intencional”
Tolerancia a
Fallas
Capacidad de un servicio para continuar operando
adecuadamente ante la ocurrencia de fallos en uno o más
componentes.
[3] [39] [40]
[26] [27]
[28] [29]
Comentario
Esta definición es aplicable 100% después de modificar de “capacidad de un servicio” a
“capacidad del SA”
Capacidad
Es la cantidad máxima de recursos disponibles de
almacenamiento y computo a brindar como servicio.
[3] [39] [23]
[40]
Comentario
No es el enfoque correcto. El autor considera que debería expresar tanto las limitaciones de
los recursos de almacenamiento o la máxima cantidad de recursos de almacenamiento
disponibles a emplear tanto en la infraestructura como para la renta.
Utilización
El porcentaje de la capacidad total de un recurso que está
en uso en un sistema.
[3] [39] [40]
[26] [27]
[28] [29]
Comentario
El autor considera que el enfoque es aplicable al diseño de SA con la especificidad que sería
“la utilización de los recursos de almacenamiento”. En este caso el autor considera que este
RNF es más bien para fines de desempeño por lo que se sugiere que sea soportado por los
gestores que se integrarán a la solución.
Throughput
Cantidad de datos libres de errores transferidos por
unidad de tiempo.
[3] [39] [40]
Comentario
Este requerimiento es abordado de manera muy general no enfocado a las especificidades
de un SA. El autor considera que el throughput debe estar dirigido a medir aspectos claves
de un SA como red y transferencia de discos.
Eficiencia
Expresa la cantidad de recursos consumidos para procesar
una cantidad determinada de trabajo. Para una misma
carga de trabajo es más eficiente aquella arquitectura que
sea capaz de cumplir los SLA utilizando menos recursos
[3] [23]
[40]
Comentario
De esta forma se encuentra un poco ambiguo el concepto. El autor considera que debe ser
enfocado mejor con respecto a cuan eficiente es SA teniendo en cuenta factores claves en
un CD como la energía y aspectos inherentes al SA como utilización de los recursos.
Tiempo de
respuesta
Tiempo que le toma a un servicio responder a la solicitud
de un cliente.
[3] [39] [40]
Comentario
Este enfoque no es el adecuado ya que se refiere a una aplicación (servicio) no al tiempo de
respuesta con parámetros propios de un SA. Se debe enfocar en tiempos de respuestas que
estén relacionados con los componentes de un SA tales como red y discos.

17
Latencia o
Demoras
Tiempo experimentado por el sistema cuando procesa
una solicitud. El tiempo incluye desde el momento en que
es generada la solicitud hasta que la respuesta es recibida.
[3] [39] [40]
Comentario
El enfoque debe ser centrado en la información (datos), que es la razón de ser del SA.
Además, se debe tener en cuenta los umbrales establecidos para saber cuándo se tienen
buenas o malas latencias.
Usabilidad
Es la medida en que un sistema, producto, o servicio
puede ser usado por usuarios específicos para lograr
objetivos específicos con eficacia, eficiencia y satisfacción
en un contexto de uso especificado
[3] [39] [23]
[26] [27]
[28] [29]
Comentario
A consideración del autor esto debe estar enfocado más bien a la facilidad de uso que posee
el sistema o los esfuerzos que se requieren para operarlo. También se debe tener en cuenta
las formas que posee el sistema para garantizar dicha usabilidad.
Interoperabilidad
La interoperabilidad es la capacidad que tiene un servicio
y/o cliente para fácilmente interactuar con otros servicios.
[3] [39] [26]
[27] [28]
[29]
Comentario
Debe enfocarse a “la capacidad que posee la solución del SA para interactuar con otros
servicios”. Debe realizarse un estudio para conocer los estándares en la industria que
permiten esto.
Portabilidad
Capacidad del cliente para mover fácilmente un servicio
de un proveedor hacia otro con interrupciones mínimas.
[3] [39]
Comentario
El autor considera que este RNF no es aplicable al diseño de SA más bien es referido a la
migración de servicios o MV de una nube a otra.
Porciento de
servicio activo
Evalúa el nivel de disponibilidad de los servicios brindados
por el sistema
[3]
Comentario
El autor considera que si aplica de forma exacta al diseño de SA. Solo recalcar que debe ser
especificado el Tiempo Total de Observación y Tiempo Total de Suspensión del SA los cuales
deben ser monitorizados para posteriormente realizar los cálculos pertinentes.
Consolidación de
los proveedores
Es el grado de prestigio, competencia y calidad que tienen
los proveedores del hardware y de las diferentes
soluciones de software que sustentan un determinado
sistema.
[3] [26] [27]
[28] [29]
Comentario
El autor está de acuerdo con la definición planteada.
Madurez de las
soluciones
Está relacionada con el tiempo que lleva una solución en
producción, el número de versiones, el intervalo de
tiempo promedio entre una versión y otra.
[3] [26] [27]
[28] [29]
Comentario
Soporte del
Proveedor
Cantidad de información que ofrecen los proveedores
acerca de sus soluciones
[3] [26] [27]
[28] [29]
Comentario
El autor está de acuerdo con la definición planteada. Solo que se debe profundizar en los
tipos de soporte que cada proveedor ofrece.

18
Factibilidad
Económica
Indica el grado de oportunidad, ahorros y eficiencia desde
el punto de vista financiero que presenta un diseño.
[3] [26] [27]
[28] [29]
Comentario
1.6. Modelos y Arquitecturas de Referencias para Sistemas de Almacenamiento
Para la implementación de un SA es necesario conocer los componentes funcionales del mismo,
así como la interacción de un componente con otro. Actualmente existen dos referencias
principales planteados por la Unión Internacional de Telecomunicaciones (UIT) [47] (Figura 7) y
la Asociación de la Industria de Almacenamiento en Redes (SNIA) [48] (Figura 6) para el
despliegue de SA. En el presente epígrafe se realizó un estudio del modelo y arquitectura
propuestos por ambas organizaciones, tomando en cuenta la ARF de NP (Figura 8) propuesta
en [49], para tomar los aportes que cada uno ofrece a la ARF de un SA.
Función de
Usuario
Función de
Negocios
Función de
Administración
Capa de Usuario
Control de
Acceso
Gestión de
Conexión
Capa de Acceso
Capacidades de
los Servicios
Capacidades para
Negocios
Capacidades de
Administración
Capa de Servicios
Orquestación de Servicios
Capa de Recursos
Recursos Físicos
Control y Abstracción de Recursos
Capa Paralela
Capacidades de
los Sistemas
Operacionales
Capacidades de
los Sistemas de
Soporte
de Negocios
Capacidades de los
Sistemas de
Seguridad
Capacidades de
Integración
Soporte para
Desarrollo
Interfaces de Acceso
Catálogo de Servicios
Aprovisionamiento
Monitoreo, Reportes,
Reglas y Gestión de
Eventos
Gestión de Fallos
Gestión de
Mantenimiento y
Actualización
Gestión de Políticas de
Servicio
Automatización de
Servicios
Gestión de Acuerdos
de Servicios
Gestión de la
Plataforma y la
Virtualización
Gestión de Interacción
inter-Nube
Catálogos de
Productos
Gestión de Cuentas
Gestión de
Subscripción
Tarificación
Cuentas
Autenticación y
Gestión de Identidad
Autorización y Gestión
de Políticas de
Seguridad
Gestión de
Encriptación
Auditorías
Anti-virus
Sistema de Facilitador
de Seguridad
Seguridad
Monitoreo
Servicios
Interacción inter-Nube
Ambiente de
Desarrollo
Gestión de
Construcción
Gestión de Pruebas
Nota:
Indica que son bloques funcionales y componentes opcionales deseables.
___ Indica que son bloques funcionales y componentes obligatorios
Figura 8 Modelo de Referencia de la Nube Privada
Aportes del Modelo de la UIT:
Figura 7 Modelo de Referencia de la UIT Figura 6 Modelo de Referencia de la SNIA

19
El modelo de referencia propuesto por la UIT define un conjunto de características
fundamentales para garantizar el adecuado funcionamiento de un SA dada distintos tipos de
clientes y para esto propone un conjunto de interfaces y estándares para asegurar la
interoperabilidad, adaptabilidad. Tiene en cuenta la seguridad del SA mediante el control de
acceso. Además, propone mecanismos para efectuar salvas, recuperación de datos
automáticamente, verificación y sincronización de datos para garantizar la consistencia de la
información, así como define qué tipo de SA utilizar ya sea en ficheros o bloques.
Aportes del Modelo de la SNIA:
El modelo de referencia de los SA para el despliegue de Nubes, planteado por la SNIA, mantiene
interfaces heredadas para ofrecer compatibilidad e incluye otras para facilitar el acceso a la
información y la gestión del sistema. Este modelo posee tres niveles básicos en su estructura:
el nivel de los servicios de recursos, el de la virtualización de estos recursos acorde a las
abstracciones de almacenamiento y el de las interfaces de acceso a la información. Los recursos
son virtualizados para permitir el almacenamiento de tablas, objetos y ficheros a través de las
abstracciones de dispositivos basados en bloques, almacenamiento de objetos y sistemas de
ficheros.
El principal aporte lo constituyen las interfaces de gestión de la información Transferencia de
Estado Representacional Completa (RESTful) unida a la Interfaz de Gestión de Datos en la Nube
(CDMI). En el primero este tipo de interfaz trata cada uno de los objetos como datos accesibles
mediante un Identificador Uniforme de Recursos (URI) único. Permite el manejo de los datos
empleando el Protocolo de Transferencia de Hipertexto (HTTP) y la ejecución de aplicaciones
en navegadores web. Toda la información basada en objetos es Creada, Obtenida, Actualizada
y Borrada (CRUD) como recursos independientes.
Existen varios ejemplos propietarios de este tipo de interfaces, sin embargo, todas soportan el
mismo grupo de operaciones, por lo que es un área que presenta las condiciones requeridas
para su estandarización. En este sentido la SNIA propone la Interfaz de Gestión Datos de Nubes
(CDMI) que permite: (1) Gestionar los contenedores y los datos que almacenan; (2) Asociar los
metadatos con los contenedores y con los objetos que contienen; (3) Descubrir por parte de los
clientes, las características disponibles por el proveedor de servicios en la Nube.
Este estándar divide las operaciones en dos tipos, uno que maneja el contenido sobre HTTP y el
otro que no, para poder proveer acceso tanto a los clientes que interaccionen con CDMI como
a los que no. Puede ser usada por aplicaciones administrativas y de gestión para el manejo de
contenedores, dominios, accesos seguros. También puede ser empleado para el monitoreo y la
obtención de información, incluso en almacenamientos accedidos mediante protocolos
propietarios.

20
CDMI es una interfaz funcional dirigida a los desarrolladores de aplicaciones que están
implementando o usando almacenamiento en la Nube, de la cual se especula que será
implementada en la mayoría de las soluciones de almacenamiento. Esta interfaz es empleada
por las aplicaciones para llevar a cabo las operaciones de recuperar, actualizar y eliminar sobre
los elementos de datos en la Nube, siendo capaz de permitirle al cliente descubrir las
capacidades de la oferta del almacenamiento en la Nube y administrar los contenedores o
volúmenes virtuales y datos en los mismos.
1.6.1 Comparación entre los modelos de referencias y la NP.
Para la comparación se tuvo en cuenta el modelo de referencia de la UIT, SNIA y de la NP ya que
en ésta el almacenamiento es uno de sus bloques funcionales por lo que la ARF de un sistema
de almacenamiento de una forma u otra se encuentra embebida en la NP. La Tabla 3 muestra
el mapeo de los dos modelos de referencia de SA y la ARF de la NP.
Capa de Usuario Final:
 Modelo de Referencia de la UIT: En DSaaS se llegó a la conclusión que sí se requiere la
capa de usuario. En este modelo de referencia no se puede apreciar una capa de
usuario.
 Modelo de Referencia de la SNIA: No se observa en la ARF, pero sí plantea el soporte
para esto de la interfaz CDMI y las basadas en RESTful con HTTP y CRUD.
 Modelo de Referencia de la Nube Privada: Si se encuentra presente.
 En esta capa el usuario puede optar por una solución de almacenamiento: (SAN,
NAS, Objetos, BD, Salvas). Lo anterior forma parte del aprovisionamiento y cada
una de las soluciones tienen requerimientos funcionales particulares:
 Función de Usuario: -Aprovisionamiento de recursos, -Configuración y
reconfiguración de los recursos solicitados, -Operaciones sobre los recursos
aprovisionados, -Alta Disponibilidad/Recuperación ante desastres
 Función de Negocios: -Administración del Negocio, -Selección y Arrendamiento
de Servicios
 Función de Administración: -Monitoreo de Servicios, -Administración de
usuarios y tenants, -Gestión de configuración
 Requerimientos Comunes: -Interfaces y terminales de usuario, -Seguridad
Capa de Acceso:
 Modelo de Referencia de la UIT: Propone una capa de acceso muy pobre. No se
especifican las funciones básicas de gestión de la conexión ni del control de acceso.
Especifican aspectos esenciales en la capa de acceso como: -Identificación de usuario y
acceso, -El uso de interfaces en las aplicaciones, -El equipo de red encargado de dar
acceso a los usuarios
 Modelo de Referencia de la SNIA: No se observa una capa de acceso definida.

21
La capa de acceso posee el control de acceso y la gestión de la conexión.
 Control de Acceso: -Acceso a los servicios, -Acceso a la función de negocio, -
Acceso a la Administración, -Acceso a Desarrollo
 Gestión de Conexión: -Balance de Carga, -Thin provisioning
Capa de Servicios:
 Modelo de Referencia de la UIT: La UIT propone una capa donde se encuentran los
servicios específicos como SAN, NAS y Salvas, pero muy pobre, no abarca las capacidades
para negocios, administración ni cómo se van a orquestar los servicios.
 Modelo de Referencia de la SNIA: Se muestra una capa de servicio de datos, pero no se
especifican de qué tipo. Al igual que el de la UIT no abarca las capacidades para negocios,
administración ni cómo se van a orquestar los servicios.
Capa de Servicios tiene dentro de ella:
 Capacidades de los servicios: -Capacidad para DSaaS, -Capacidad para IaaS
 Capacidades para negocios: -Capacidad para acceder al componente funcional
de negocios, -Gestión de Servicios inter-Nubes
 Capacidades de administración: Proporciona un conjunto de capacidades para
acceder a la función de administración relacionada con la provisión de servicios
en la nube.
 Orquestación de los servicios: Proporciona coordinación, agregación y
composición de múltiples componentes de servicio para entregar el servicio en
la nube.
Capa de Recursos:
 Modelo de Referencia de la UIT: No existe delimitada la capa de recursos en sí, todo se
encuentra embebido dentro de su capa de infraestructura. Aunque hacen referencia a un
aspecto de la capa de recursos como la gestión de recursos virtuales
 Modelo de Referencia de la SNIA: Al igual que el modelo de la UIT la capa de recursos no
se encuentra visible. Hacen referencia a un aspecto de dicha capa que es recursos bajo
demanda perteneciente a los recursos virtuales.
Dentro de ella se encuentra:
 El control y abstracción de recursos: -Control y orquestación de recursos, -
Recursos de abstracción (Virtualización de almacenamiento), -Recursos
virtuales (Almacenamiento virtual)

22
 Recursos físicos: -Almacenamiento (Características del nodo de almacenamiento en
cuanto a tipo de: Discos, CPU, RAM, etc.), -Red (Red del SA, equipos de interconexión)
Capa Paralela:
 Modelo de Referencia de la UIT: Se encuentran presentes algunas funciones de dicha capa
como: interfaces de acceso a la información, clúster de monitoreo de la infraestructura y
autenticación y gestión de identidad
 Modelo de Referencia de la SNIA: Se encuentran presentes algunas funciones de dicha
capa como: interfaces de acceso a la información y gestión de los datos (CDMI)
 Modelo de Referencia de la Nube Privada: Si se encuentra presente. Ver Anexo B
1.6.2 Requerimientos funcionales a cumplir por el SA.
En un estudio realizado por el grupo de investigación de la Nube de Telemática de la Universidad
Tecnológica de La Habana, Cuba se pudieron detectar una serie RF a cumplir por un SA según
las capas que componen la ARF de la Nube donde el almacenamiento constituye un bloque de
la misma. Esto es de gran importante principalmente a la hora de elegir el software el cual debe
cumplir estos requerimientos.
A continuación, en la Tabla 8 se hace mención a los RF más importantes detectados y algunos
opcionales pero deseables:
Tabla 8 RNF a cumplir por el SA de forma general
Capa de la
Arquitectura de
Referencia Funcional
Requerimiento Funcional Tipo Principales
Referencias
Capa de Usuario Aprovisionamiento de Recursos Obligatorio [50] [51]
Soporte de múltiples interfaces de
almacenamiento
Obligatorio [47] [51]
Mecanismo de manejo de la
información (escritura, lectura,
actualización, eliminación)
Obligatorio [52]
Formas en que el usuario adquiere
la infraestructura
Opcional pero
deseable
[50] [51]
Solicitud del servicio por
aplicaciones de terceros
Opcional pero
deseable
[53]
Funciones de snapshot a los
distintos niveles
Opcional pero
deseable
[52] [54]
Capa de Acceso Autenticación de usuario Obligatorio [47] [55] [56]
[51]
Detección de intrusos Obligatorio [57]
Balance de carga Obligatorio [51][55] [58]
[59]
Asignar el espacio de
almacenamiento necesario
Obligatorio [55]

23
Tipos de accesos: negocios,
desarrollo, mantenimiento
Opcional pero
deseable
[60] [61]
Capa de Servicios Soporte de NAS, SAN Obligatorio
Proveer recuperación de datos,
salvas y verificación de la
información.
Soporte de tolerancia a Fallas Obligatorio
Capacidad para la administración Obligatorio [60] [61]
Orquestación de servicio. Obligatorio [51][60] [61]
Políticas de Migración Opcional pero
deseable
[52]
Modos de ejecución de salvas Opcional pero
deseable
[51] [52]
Capa de Recursos.
Recursos virtuales
Virtualización de almacenamiento
debe soportar: Ficheros, Bloques y
Objetos
Creación de Pools Obligatorio
Data de-duplicación Obligatorio [47] [51]
Thin provisioning Opcional pero
deseable
[51]
Balance de carga Opcional pero
deseable
Capa Paralela Monitoreo de recursos Obligatorio [63] [51][60]
Reportes Obligatorio [63] [51][60]
Gestión de Fallas Obligatorio [47][51][60]
Antivirus Obligatorio [58]
Catálogos de Productos Obligatorio [51][60]
1.7. Sistemas de Almacenamiento en la actualidad.
1.7.1 DAS, NAS y SAN
En la actualidad, los SAs básicamente empleados en CDs, son: DAS, NAS y SAN.
Estos sistemas, unidos a la evolución en las arquitecturas de red y los protocolos referidos al
almacenamiento, son los empleados en la actualidad en CDs tradicionales y en CDs que
soportan el paradigma de la CN. Para estos últimos, el almacenamiento ha evolucionado hasta
surgir tecnologías y conceptos como el Almacenamiento Unificado y el Almacenamiento en la
Nube, que se nutren de los mejores atributos de los SAs anteriores hasta derivar en soluciones
de almacenamiento con mayores prestaciones y funcionalidades.
ALMACENAMIENTO DIRECTAMENTE CONECTADO (DAS)

24
DAS es el nivel más básico almacenamiento, en el cual los dispositivos de almacenamiento
forman parte de la estación de trabajo, o están directamente conectados a un servidor (Figura
9) [64]. Por ser el primer modelo de almacenamiento ampliamente utilizado, los productos DAS
aún comprenden una extensa gama de los SAs instalados en las infraestructuras de
telecomunicaciones y a pesar de que la implementación del almacenamiento en red (NAS y SAN)
está creciendo más rápido que DAS, este modelo aún es aplicable por su sencillez de diseño y
explotación y por su bajo costo inicial [24].
Este modelo no se abordará ni se propondrá como solución en este trabajo ya que en la
actualidad los CD van enfocados a explotar otras potencialidades tales como alta disponibilidad,
redundancia y escalabilidad las cuales no son alcanzables utilizando DAS [65] [66]. .
ALMACENAMIENTO CONECTADO A LA RED (NAS)
La tecnología NAS, surgió como respuesta a los problemas asociados a los sistemas DAS [64]. De
manera general, un dispositivo NAS está compuesto por un arreglo de discos duros conectados
como Arreglo Redundante de Discos Independientes (RAID) [67]–[70] y software de gestión, y
está completamente dedicado a dar acceso a los clientes al almacenamiento, empleando
protocolos de compartición de ficheros como: Sistema de Ficheros en Red (NFS) [71] [72] y
Sistema de Ficheros de Internet Común (CIFS) [73]. Además pueden emplearse otros protocolos
como: Protocolo de Transferencia de Archivos (FTP) [71] [74], [75] o Protocolo de Transferencia
de Archivos Trivial (TFTP) [71]. Lo anterior permite que un dispositivo NAS tenga una gran
utilidad a la hora de compartir archivos e información entre diferentes tipos de plataforma ya
que sus protocolos se encuentran estandarizados por lo que puede ser compatible con la
mayoría de los SO más utilizados en la actualidad dígase Windows, Linux o Mac, por lo que un
dispositivo NAS ofrece una mayor interoperabilidad que un SAN.
En cuanto a su diseño el dispositivo usualmente se conecta directo a la a la red de área local
(LAN) como se muestra en la Figura 10 [24].
Figura 9 Esquema del Sistema DAS

25
Dado que los protocolos de comunicaciones empleados por NAS son basados en ficheros, el
cliente solicita el fichero completo al servidor y lo maneja localmente [64].
Una NAS posee Funcionalidad plug-and-play ya que estos dispositivos solo requieren ser
conectados a la red para su funcionamiento, adquieren su dirección IP y aparecen
automáticamente como un dispositivo de almacenamiento adicional permitiendo una mayor
velocidad de despliegue. En el ANEXO J se pueden encontrar otras de sus principales
características.
La principal desventaja de NAS es que si no es bien dimensionada la red puede congestionarse
el servidor ya que comparte la misma conexión LAN que el cliente, por lo que no se recomienda
para entornos donde existan aplicaciones que demanden alto throughput de red ni para la
virtualización ya que un sistema de ficheros no es el más indicada para estos fines sino un
sistema basado en bloques.
RED DE ÁREA DE ALMACENAMIENTO (SAN)
La Asociación de la Industria del Almacenamiento en Red (SNIA), define una SAN como una red
especializada cuyo propósito fundamental es la transferencia de datos entre sistemas de
cómputo y dispositivos de almacenamiento. Siendo así, una SAN comprende: la infraestructura
de comunicación que provee conexiones físicas y una capa de gestión encargada de organizar
las conexiones, elementos de almacenamiento y sistemas de cómputo, de manera tal que la
transferencia sea robusta y segura [76].
Según [76] una SAN permite conexiones cualquiera-a-cualquiera a través de la red, empleando
dispositivos de interconexión tales como routers, puertas de enlace (gateways), hubs,
conmutadores y otros. Elimina la tradicional conexión dedicada entre servidor y
almacenamiento y el concepto de que el servidor “comprende y gestiona” los dispositivos de
almacenamiento. También elimina toda restricción para el volumen de datos que puede
acceder un servidor, usualmente limitada por el número de dispositivos de almacenamiento
conectados a un servidor individual. Por el contrario, una SAN introduce la flexibilidad de
permitir que un servidor o varios servidores heterogéneos compartan una misma utilidad de
Figura 10 Esquema del Sistema NAS

26
almacenamiento que, adicionalmente, puede estar situada físicamente distante. En el ANEXO J
se pueden encontrar otras de sus principales características.
En la Figura 11 [24] se muestra el esquema básico de una SAN. Pueden observarse sus
componentes principales y de manera simplificada intuir las ventajas que implica aislar en la red
el tráfico de almacenamiento o dedicar una red con este solo propósito.
ALMACENAMIENTO UNIFICADO
El almacenamiento unificado, es un sistema basado en la convergencia de tecnologías de
almacenamiento. Básicamente, permite la integración en una misma plataforma, de sistemas
que brindan acceso al almacenamiento basado en ficheros (NAS) y basado en bloques (SAN).
La implementación de almacenamiento unificado permite la reducción de los requerimientos y
despliegue de hardware. Esto trae aparejado una simplificación importante, de la gestión del
SA [24].
Ventajas del almacenamiento unificado:
* Reduce el número de tecnologías requeridas para la solución de almacenamiento: se simplifican
las tareas de mantenimiento y disminuye la cantidad de personal calificado requerido para la
atención al mismo.
* Reduce los costos de despliegue y explotación del almacenamiento.
* Flexibilidadenlaagrupaciónde capacidades de almacenamiento: el soporte conjunto de acceso
basado en fichero y en bloques al almacenamiento, elimina la necesidad de planificar
capacidades de almacenamiento para cada sistema por separado.
Actualmente, lo que se pretende con este concepto, es aprovechar las bondades propias del
estándar Ethernet para manejar el tráfico de almacenamiento y de esta manera integrar las
diferentes tecnologías relacionadas.
Figura 11 Esquema del Sistema SAN

27
1.7.2 Sistemas basados en Objetos, Bloques y Ficheros.
Para poder comprender el por qué utilizar una u otra arquitectura de almacenamiento es
necesario comprender su nivel más bajo que no es más que el tipo de almacenamiento que
presenta. Según el principio de funcionamiento de cada uno será la utilidad que se le dará a la
arquitectura que lo pueda desplegar. A continuación, un breve resumen de sus características:
a) Objetos [77] [78] [79]
El almacenamiento de objetos (Figura 12) es típicamente implementado en una SAN ya que
requiere un alto flujo de información, pero también puede ser implementado, en menor medida
en entornos NAS. Uno de los principios de diseño del almacenamiento de objetos es abstraer
algunas de las capas inferiores de almacenamiento lejos de los administradores y las
aplicaciones. Por lo tanto, los datos se exponen y se administran como objetos en lugar de
archivos o bloques. Los objetos contienen propiedades descriptivas adicionales que se pueden
utilizar para una mejor indexación o gestión. Los administradores no tienen que realizar
funciones de almacenamiento de nivel inferior, como la construcción y la gestión de volúmenes
lógicos para utilizar la capacidad de disco o la configuración de los niveles de RAID para hacer
frente a fallos de disco.
El almacenamiento de objetos también permite el direccionamiento y la identificación de
objetos individuales por algo más que el nombre de archivo y la ruta del archivo. El
almacenamiento de objetos agrega un identificador único dentro de un cubo o en todo el
sistema para admitir espacios de nombres mucho más grandes y eliminar colisiones de
nombres.
El almacenamiento de objetos separa explícitamente los metadatos de los archivos de los datos
para soportar capacidades adicionales: A diferencia de los metadatos fijos en los sistemas de
archivos (nombre de archivo, fecha de creación, tipo, etc.), el almacenamiento de objetos
proporciona metadatos de función completa a nivel de objeto para:
 Captura de información específica de la aplicación o específica del usuario para
mejores propósitos de indexación
Figura 12 Esquema del
Almacenamiento de Objetos

28
 Apoyar políticas de administración de datos (por ejemplo, una política para
impulsar el movimiento de un objeto de un nivel de almacenamiento a otro)
 Centralizar la administración del almacenamiento en muchos nodos y clústeres
individuales
 Optimizar el almacenamiento de metadatos (por ejemplo, almacenamiento de
valores de la base de datos o de las claves) y almacenamiento en caché /
indexación (cuando los metadatos autorizados se encapsulan con los metadatos
dentro del objeto) independientemente del almacenamiento de datos (por
ejemplo, almacenamiento binario no estructurado)
Además, en algunas implementaciones de sistemas de archivos basadas en objetos los clientes
del sistema de archivos solo contactan los servidores de metadatos una vez cuando se abre el
archivo y luego obtienen el contenido directamente a través de los servidores de
almacenamiento de objetos (en comparación con los sistemas de archivos basados en bloques
que requieren acceso constante a los metadatos)
Otra de las funcionalidades son que los objetos de datos se pueden configurar en una base por
archivo para permitir el ancho de banda adaptable, incluso a través de múltiples servidores de
almacenamiento de objetos, soportando optimizaciones en ancho de banda y E / S
Interfaces
El almacenamiento de objetos proporciona interfaces programáticas que permiten a las
aplicaciones manipular datos. En el nivel de base, esto incluye funciones CRUD para operaciones
básicas de lectura, escritura y supresión. Algunas implementaciones de almacenamiento de
objetos van más allá, soportando funcionalidades adicionales como el control de versiones de
objetos, la replicación de objetos y el movimiento de objetos entre diferentes niveles y tipos de
almacenamiento. La mayoría de las implementaciones de API están basadas en ReST,
permitiendo el uso de muchas llamadas HTTP estándar.
Utilización
Los sistemas de almacenamiento de objetos permiten la retención de cantidades masivas de
datos no estructurados. El almacenamiento de objetos se utiliza con fines tales como almacenar
grandes volúmenes fotos, canciones o videos que poseen una descripción o datos adicionales.

29
b) Bloques [80] [81]
El almacenamiento en bloque (Figura 13) es un tipo de almacenamiento de datos que se suele
utilizar en entornos de red de área de almacenamiento (SAN) donde los datos se almacenan en
volúmenes de tamaño uniforme, también denominados bloques. Cada volumen de
almacenamiento puede ser tratado como una unidad de disco independiente y controlado por
un sistema operativo de servidor externo. Este dispositivo de bloque puede ser montado por el
sistema operativo huésped como si fuera un disco físico. Al almacenar grandes cantidades de
datos, los archivos se dividen en trozos más pequeños de un tamaño fijo, los "bloques", que se
distribuyen entre los nodos de almacenamiento.
Interfaces
Estos bloques son controlados por el sistema operativo basado en servidor, y generalmente se
accede por los protocolos Fibre Channel (FC), Fibre Channel over Ethernet (FCoE) o iSCSI.
Utilización
Como cada bloque actúa como un disco duro individual y es configurado por el administrador
de almacenamiento, resulta ideal para entornos de virtualización ya que cada bloque admite el
formateo individual de sistemas de archivos como NFS, NTFS o VMFS (VMware) que son
requeridos por las aplicaciones.
Mientras que los dispositivos de almacenamiento de bloques tienden a ser más complejos y
costosos que el almacenamiento de archivos, también tienden a ser más flexibles y
proporcionan un mejor rendimiento.
c) Ficheros
Figura 13 Esquema del Almacenamiento de
Bloques

30
El almacenamiento en ficheros (Figura 14) es un tipo de almacenamiento de datos que se suele
utilizar en entornos de NAS. Sus principales funciones son la asignación de espacio a los archivos,
la administración del espacio libre y del acceso a los datos resguardados. Estructuran la
información guardada en un dispositivo de almacenamiento de datos o unidad de
almacenamiento (normalmente un disco duro de una computadora), que luego será
representada ya sea textual o gráficamente utilizando un gestor de archivos.
La estructura de directorios suele ser jerárquica, ramificada o "en árbol", aunque en algún caso
podría ser plana. En algunos sistemas de archivos los nombres de archivos son estructurados,
con sintaxis especiales para extensiones de archivos y números de versión. En otros, los
nombres de archivos son simplemente cadenas de texto y los metadatos de cada archivo son
alojados separadamente.
En los sistemas de archivos jerárquicos, usualmente, se declara la ubicación precisa de un
archivo con una cadena de texto llamada ruta (path, en inglés). La nomenclatura para rutas varía
ligeramente de sistema en sistema, pero mantienen por lo general una misma estructura. Una
ruta viene dada por una sucesión de nombres de directorios y subdirectorios, ordenados
jerárquicamente de izquierda a derecha y separados por algún carácter especial que suele ser
una barra diagonal (/) o barra diagonal invertida () y puede terminar en el nombre de un archivo
presente en la última rama de directorios especificada.
Interfaces
Los tipos de interfaces más utilizadas en el almacenamiento de ficheros son: (NFS) (CIFS) (FTP)
(TFTP) y SMB.
Utilización
Los sistemas de ficheros normalmente son utilizados para guardar y compartir información en
una red local. También se puede utilizar como medio para brindar DSaaS.
Figura 14 Esquema del Almacenamiento de Ficheros

31
1.7.3 Aspectos para la selección de un sistema NAS o SAN
La elección de un sistema NAS o SAN está muy estrictamente vinculado a los objetivos del
negocio y a las aplicaciones que sobre estos sistemas se desplegarán. Es por ello que conocer
en qué casos utilizar uno u otro es de vital importancia para el correcto desempeño de los
servicios que sobre estos se desplegarán.
En base a lo tratado en los epígrafes anteriores ya es posible definir la misión de una SAN o NAS
en un CD. A continuación, en la Tabla 9 se muestran ejemplos de cuando es conveniente la
utilización de SAN o NAS dependiendo de las aplicaciones que sobre esta se desplegarán.
Tabla 9 Aplicaciones de SAN o NAS
NAS SAN
1-Servidor de Archivos [82] 1-Bases de datos [83] [84] [85]
2-Compartir archivos [82] 2- Almacenamiento en clúster [26] [86]
3- Almacenamiento de contenido
(fotos, videos, etc.) [87]
3-Aplicaciones de mensajería [88]
4-Almacenamiento de metadatos 4-Replicación de datos [89] [88]
5-Repositorios de correos [90] [91] 5-Sitios Webs [88]
6-Almacenamiento en clúster [92] 6- Discos duros de máquinas virtuales [88] [93]
7-Guardar Salvas [87] [94]
7- Cualquier tipo de aplicación que requiera bajas
latencias y alto rendimiento
También es necesario conocer cuando elegir uno u otro en dependencia de los RNF que debe
cumplir el SA. Para ello la Tabla 10 muestra una comparativa realizada por el autor en base al
principio de funcionamiento y a la documentación recopilada en cuanto al cumplimiento por
parte de un sistema u otro en cuanto a los RNF. Las siglas B, M, A significan Bajo, Medio y Alto
respectivamente.
Tabla 10 Elección de SAN o NAS en cuanto a los RNF
Dimensiones Categoría Atributos
SAN NAS
B M A B M A
Adaptabilidad
Escalabilidad
Horizontal X X
Comentario
Ambos presentan altos índices de escalabilidad horizontal
pudiéndose añadir nodos aumentando así la capacidad
total de almacenamiento. La limitante es impuesta por la
topología de red y la solución de software.
Vertical
Comentario
No depende del sistema sino del Hardware donde se va a
implementar
Compatibilidad
Interoperabilidad X X
Comentario

32
En este aspecto una NAS posee una mayor
interoperabilidad por la variedad de protocolos para
transferir la información y en menor medida la SAN.
Flexibilidad
Comentario
Depende de las potencialidades del software del SA y sus
posibilidades a la hora de integrarse a otras soluciones.
Compatibilidad X X
Comentario
La complejidad de los sistemas SAN hace que su
compatibilidad con diferentes tipos de gestores sea
menor a la de una NAS.
QoS
Desempeño
Capacidad X X
Comentario
Ambos sistemas pueden soportar altas capacidades de
información.
Utilización
Comentario
Los índices de utilización es un aspecto que no depende
de la solución, sino de cómo el usuario lo explota.
Throughput X X
Tiempo de Resp. X X X
Latencias X X X
Comentario
Una SAN mayormente se utiliza para escenarios donde se
requiera un alto throughput, así como bajos tiempo de
respuesta y latencia. La NAS al utilizar una conexión LAN
no presenta el mismo throughput que una SAN y
encuentra limitado por la congestión de la Red a la que
está conectado.
Eficiencia
Comentario
Depende del equipamiento y su Hardware.
Disponibilidad
% servicio activo
Disponibilidad
Comentario
Depende de situaciones ajenas al funcionamiento del
sistema.
Tolerancia a Fallas X x
Comentario
Ambos presentan algoritmos que los hacen tolerantes a
fallas.
Recuperación ante fallas X X
Confiabilidad X X

Procedimiento de diseño de Sistemas de Almacenamiento para Centros de Datos en Pyme ern

Procedimiento de diseño de Sistemas de Almacenamiento para Centros de Datos en Pyme ern

Recomendados

Recomendados

Más contenido relacionado

Similar a Procedimiento de diseño de Sistemas de Almacenamiento para Centros de Datos en Pyme ern

Similar a Procedimiento de diseño de Sistemas de Almacenamiento para Centros de Datos en Pyme ern (20)

Último

Último (20)

Procedimiento de diseño de Sistemas de Almacenamiento para Centros de Datos en Pyme ern