Tesis Art

See discussions, stats, and author profiles for this publication at: https://www.researchgate.
net/publication/320333458
PROCEDIMIENTO DE DISEÑO DE SISTEMAS DE ALMACENAMIENTO PARA

CENTROS DE DATOS EN PYME
Thesis · January 2017
CITATIONS READS
0 87
1 author:
Arturo Díaz Crespo

Universidad Tecnológica de la Habana, José Antonio Echeverría
1 PUBLICATION 0 CITATIONS
SEE PROFILE
All content following this page was uploaded by Arturo Díaz Crespo on 11 October 2017.
The user has requested enhancement of the downloaded file.

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
DEDICATORIA
A mi familia…
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
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
1
Introducción
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.
2
Introducción
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.

Datos”. En este capítulo se pone a prueba el método confeccionado mediante su aplicación en
un centro de datos.
3
considerados relevantes en el proceso de diseño.”
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]
4
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
5
 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.
6
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:
Bibliografía consultada
Publicaciones Académicas
2
3
Organismos de Estandarización
2
Proveedores de Nube, Hardware y
1 Software privados
Proveedores de SLCA de SA
Gestores de Nubes SLCA

4 4
Proveedores Hardawre COTS
Figura 2 Referencias consultadas en la evaluación de los métodos de diseño
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.
7
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.
Figura 4 Cuadrante Mágico de Gartner Figura 3 Cuadrante Mágico de Gartner Principales

Proveedores de Soluciones de Proveedores de Nube e IaaS
Almacenamiento
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.
8
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)
Figura 5 Principales proveedores de hardware

para SA
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]
9
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
% de
cumpl
Aspecto Comentario
imien
to
Estudio de la misión,
Este aspecto es uno de los que menos cumplimiento
visión, la estructura
tiene según los resultados ya que no se pudo verificar
organizacional de la 15%
su aplicación exceptuando a 7,10 y 11 los cuales si
entidad cliente y sus
abogan por el estudio de este aspecto.
características
Definición de los En cuanto a este indicador también se aprecia poco
20%
objetivos del negocio interés en él solo 2,7,10 y 11 abogan por su realización.
Caracterización del Respecto a este parámetro de gran importancia se
estado inicial del pudo apreciar que tampoco se tiene mucho en cuenta,
sistema solo es propuesto por 1,2,6,7,8,10 y la mayoría asume 30%
(infraestructura y que la implementación se realizará en escenarios
servicios) donde no existe aún ninguna infraestructura.
En este caso si se aprecia un gran cumplimiento por
gran parte de los investigados dada la importancia de
Definición de
establecer dichas restricciones las cuales abarcaron 75%
restricciones
tanto restricciones de hardware, software, así como
área de instalación.
Aquí solo 6 y 7 proponen que se deben caracterizar los
Definición de los
servicios y/o aplicaciones que utilizaran el SA, pero no
servicios y/o
ofrecen ninguna herramienta para hacerlo. Por su parte
aplicaciones que 20%
10 y 11 lo proponen y ofrecen una pequeña
utilizarán el SA, y su
herramienta para hacerlo, pero muy pobre por lo que
caracterización
debe ser mejorada.
Aquí 1 y 7 proponen que se deben conocer los RNF que
debe cumplir el SA, no propone ni presenta ningunos.
Definición de los RNF Por su parte 10 y 11 si proponen RNF definidos a
35%
a soportar por el SA. 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.
La división de fases es cumplida por todos excepto por
División de fases los Softwares y los Proveedores COTS en los cuales no 60%
se definen fases de diseño.
FASE II “Diseño lógico”:
Tabla 3 Resultados del análisis de la Fase II
10
% de
cumpl
Aspecto Comentario
imien
to
En este aspecto la mayoría aboga por un sistema u otro
según variados aspectos los cuales son diferentes en
Estudio del tipo de SA
uno u otro. Es necesario una investigación para definir
a utilizar según los 58%
de manera precisa cuando SAN o NAS. Están exentos de
RNF
este análisis los softwares y los proveedores COTS ya
que no tiene sentido el estudio de este aspecto en ellos
Identificación de las
características de los
Este aspecto es muy desarrollado por casi todos ya que
discos a emplear, así
la mayoría propone las características que deben tener
como las 55%
los discos a utilizar y realizan una breve explicación de
controladoras a
lo que puede ofrecer uno u otro tipo de disco.
utilizar según los RNF
a cumplir.
Dimensionamiento
Muy poco desarrollado, solo es tomado en cuenta y
del SA teniendo en
brindan una pequeña herramienta para su realización
cuenta las
por 10 y 11. Por su parte 18 ofrece una breve
características de los 15%
explicación del porqué es necesario una planificación
servicios y
de las capacidades y otros aspectos que tributan al
aplicaciones que se
dimensionamiento.
demanden.
Identificación de las
La mayoría logra identificar las tecnologías de
características de las
interconexión y las topologías necesarias para
tecnologías de
desplegar su sistema e incluso ofrecen algunos 75%
interconexión de red,
ejemplos de diferentes despliegues con distintas
así como los
configuraciones.
dispositivos a utilizar.
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
División de fases 15%
forma simultánea. Solo se pudo apreciar una
diferenciación de fases en 10, 11 y 12.
FASE III “Diseño físico”:
Tabla 4 Resultados del análisis de la Fase III
% de
cumpl
Aspecto Comentario
imien
to
Selección de la En este aspecto solo 10 y 11 seleccionan de acorde a
solución (SAN/NAS) los RNF y explican el porqué de su selección. En los
del SA que se acople a demás no queda bien fundamentada el porqué de una
12%
las características de u otra o el diseño corresponde a una u otra tecnología
la empresa según los en específico. Quedan exentos de este análisis los
RNF a cumplir. proveedores COTS.
11
La mayoría elige un software que se corresponde con la

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

Identificar las IOPS11, throughput, uso de red, pero no establecen
métricas para conocer umbrales de buen comportamiento de las mismas
35%
si el sistema responde como se puede ver en 1,3,4,5,7. Por su parte en 10 y 11
de manera eficiente. se pueden ver con mayor claridad las métricas
correspondientes a un SA.
La mayoría realizan pruebas, pero solo exponen los
resultados, no exponen las características de estas
Ejecución de las pruebas ni el escenario donde se realizaron ni las
distintas pruebas al herramientas que utilizaron. Solo se pudo ver con 50%
SA. claridad en 10 y 11 que proponen un modelo de
pruebas bien definido y las herramientas para
realizarlas.
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
Optimización. optimizarlos con la documentación correspondiente, 50%
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.
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
13
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
[38] [1]
procedimiento para hacerlo.
Indican que se deben caracterizan las aplicaciones, pero no lo
[24] [23]
realizan ni ofrecen procedimientos o métricas.
Exponen métricas que pueden ser de interés a la hora de
[35] [36] [37] [3]
caracterizar las aplicaciones.
Implementan el diseño de un SA sin caracterizar las
[14] [9] [10] [15] [16] [17]
aplicaciones, ni indicarlo, ni ofrecer métricas ni
[18] [19] [20] [21] [22]
procedimientos.
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
14
RNF Descripción Referencias

Indica la capacidad del sistema para incrementar la
Escalabilidad [3] [39] [23]
capacidad del hardware y software existente añadiendo
Vertical [40]
recursos a estos.
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.
Indica la capacidad del Sistema de aumentar su capacidad
[3] [39] [23]
mediante la agregación de nuevas entidades de hardware
Escalabilidad [40] [26]
o software (nodos de procesamiento, almacenamiento),
Horizontal [27] [28]
de manera económicamente factible, manteniendo los
[29]
niveles de desempeño requeridos.
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”.
El grado al cual un sistema es capaz de adaptarse a los
cambios en las cargas de trabajo a través del
Elasticidad [3] [39] [40]
aprovisionamiento y desaprovisionamiento de recursos de
manera autonómica.
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.
La compatibilidad como atributo se refiere al soporte que
tiene la arquitectura para diferentes estándares, [3] [39] [40]
Compatibilidad tecnologías, y sus evoluciones con el propósito de ser [26] [27]
compatible con diferentes proveedores de hardware y [28] [29]
soluciones de software.
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.
[3] [39] [40]
La flexibilidad es la habilidad de añadir o eliminar
Flexibilidad [26] [27]
funcionalidades o características a los servicios existentes.
[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.
Refleja las medidas de cómo operan los servicios sin fallas
[3] [39] [23]
Confiabilidad bajo condiciones dadas durante un período de tiempo
[40]
determinado.
15
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.
Es el grado en el que un servicio es capaz de rápidamente [3] [23] [40]
Recuperación
volver a su estado normal de operación después de una [26] [27]
ante fallas
interrupción no planificada. [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”
Capacidad de un servicio para continuar operando [3] [39] [40]
Tolerancia a
adecuadamente ante la ocurrencia de fallos en uno o más [26] [27]
Fallas
componentes. [28] [29]
Comentario
Esta definición es aplicable 100% después de modificar de “capacidad de un servicio” a
“capacidad del SA”
Es la cantidad máxima de recursos disponibles de [3] [39] [23]
Capacidad
almacenamiento y computo a brindar como servicio. [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.
[3] [39] [40]
El porcentaje de la capacidad total de un recurso que está
Utilización [26] [27]
en uso en un sistema.
[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.
Cantidad de datos libres de errores transferidos por
Throughput [3] [39] [40]
unidad de tiempo.
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.
Expresa la cantidad de recursos consumidos para procesar
una cantidad determinada de trabajo. Para una misma [3] [23]
Eficiencia
carga de trabajo es más eficiente aquella arquitectura que [40]
sea capaz de cumplir los SLA utilizando menos recursos
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 Tiempo que le toma a un servicio responder a la solicitud
[3] [39] [40]
respuesta de un cliente.
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.
16
Tiempo experimentado por el sistema cuando procesa

Latencia o
una solicitud. El tiempo incluye desde el momento en que [3] [39] [40]
Demoras
es generada la solicitud hasta que la respuesta es recibida.
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.
Es la medida en que un sistema, producto, o servicio
[3] [39] [23]
puede ser usado por usuarios específicos para lograr
Usabilidad [26] [27]
objetivos específicos con eficacia, eficiencia y satisfacción
[28] [29]
en un contexto de uso especificado
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.
[3] [39] [26]
La interoperabilidad es la capacidad que tiene un servicio
Interoperabilidad [27] [28]
y/o cliente para fácilmente interactuar con otros servicios.
[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.
Capacidad del cliente para mover fácilmente un servicio
Portabilidad [3] [39]
de un proveedor hacia otro con interrupciones mínimas.
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 Evalúa el nivel de disponibilidad de los servicios brindados
[3]
servicio activo por el sistema
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.
Es el grado de prestigio, competencia y calidad que tienen
Consolidación de los proveedores del hardware y de las diferentes [3] [26] [27]
los proveedores soluciones de software que sustentan un determinado [28] [29]
sistema.
Comentario
El autor está de acuerdo con la definición planteada.
Está relacionada con el tiempo que lleva una solución en
Madurez de las [3] [26] [27]
producción, el número de versiones, el intervalo de
soluciones [28] [29]
tiempo promedio entre una versión y otra.
Comentario
Soporte del Cantidad de información que ofrecen los proveedores [3] [26] [27]
Proveedor acerca de sus soluciones [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.
17
Factibilidad Indica el grado de oportunidad, ahorros y eficiencia desde [3] [26] [27]
Económica el punto de vista financiero que presenta un diseño. [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.
Figura 7 Modelo de Referencia de la UIT Figura 6 Modelo de Referencia de la SNIA
Capa de Usuario
Capa Paralela
Función de Función de Función de
Usuario Negocios Administración
Capacidades de Capacidades de Capacidades de los Capacidades de Soporte para
los Sistemas los Sistemas de Sistemas de Integración Desarrollo
Operacionales Soporte Seguridad
de Negocios
Capa de Acceso Interfaces de Acceso
Autenticación y Interfaces de Acceso Interfaces de Acceso
Control de Gestión de Catálogo de Servicios Catálogos de Gestión de Identidad
Acceso Conexión Productos
Aprovisionamiento Seguridad Ambiente de
Autorización y Gestión Desarrollo
Monitoreo, Reportes, Gestión de Cuentas
de Políticas de
Reglas y Gestión de
Capa de Servicios Seguridad Monitoreo
Eventos Gestión de
Gestión de Construcción
Capacidades de Capacidades para Capacidades de Gestión de Fallos
los Servicios Negocios Administración Subscripción
Gestión de Servicios
Gestión de
Encriptación Gestión de Pruebas
Mantenimiento y
Actualización Tarificación
Orquestación de Servicios
Gestión de Políticas de Interacción inter-Nube
Servicio Cuentas Auditorías
Automatización de
Servicios
Gestión de Acuerdos
Capa de Recursos de Servicios
Interfaces de Acceso Anti-virus
Control y Abstracción de Recursos Gestión de la

Plataforma y la Sistema de Facilitador
Virtualización de Seguridad
Recursos Físicos Gestión de Interacción

inter-Nube Interfaces de Acceso
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:
18
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.
19
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.
20

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)
21
 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 Requerimiento Funcional Tipo Principales

Arquitectura de Referencias
Referencia Funcional
Capa de Usuario Aprovisionamiento de Recursos Obligatorio [50] [51]
Soporte de múltiples interfaces de Obligatorio [47] [51]
almacenamiento
Mecanismo de manejo de la Obligatorio [52]
información (escritura, lectura,
actualización, eliminación)
Formas en que el usuario adquiere Opcional pero [50] [51]
la infraestructura deseable
Solicitud del servicio por Opcional pero [53]
aplicaciones de terceros deseable
Funciones de snapshot a los Opcional pero [52] [54]
distintos niveles deseable
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 Obligatorio [55]
almacenamiento necesario
22
Tipos de accesos: negocios, Opcional pero [60] [61]

desarrollo, mantenimiento deseable
Capa de Servicios Soporte de NAS, SAN Obligatorio

Proveer recuperación de datos, Obligatorio [47] [52]
salvas y verificación de la
información.
Soporte de tolerancia a FallasObligatorio
Capacidad para la administración
Obligatorio [60] [61]
Orquestación de servicio. Obligatorio [51][60] [61]
Políticas de Migración Opcional pero [52]
deseable
Modos de ejecución de salvas Opcional pero [51] [52]
deseable
Capa de Recursos. Virtualización de almacenamiento Obligatorio [51] [62]
Recursos virtuales debe soportar: Ficheros, Bloques y
Objetos
Creación de Pools Obligatorio
Data de-duplicación Obligatorio [47] [51]
Thin provisioning Opcional pero [51]
deseable
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)
23
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]. .
Figura 9 Esquema del Sistema DAS
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].
24
Figura 10 Esquema del Sistema NAS
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
25
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.
Figura 11 Esquema del Sistema SAN
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.
* Flexibilidad en la agrupación de 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.
26
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]
Figura 12 Esquema del

Almacenamiento de Objetos
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
27
 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.
28
b) Bloques [80] [81]
Figura 13 Esquema del Almacenamiento de

Bloques
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
29
Figura 14 Esquema del Almacenamiento de Ficheros
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.
30
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 3-Aplicaciones de mensajería [88]

(fotos, videos, etc.) [87]
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- Cualquier tipo de aplicación que requiera bajas

7-Guardar Salvas [87] [94]
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
SAN NAS
Dimensiones Categoría Atributos
B M A B M A
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
Escalabilidad
topología de red y la solución de software.
Adaptabilidad
Vertical
Comentario
No depende del sistema sino del Hardware donde se va a
implementar
Interoperabilidad X X
Compatibilidad
Comentario
31
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.
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
Desempeño Latencias X X X
Comentario
Una SAN mayormente se utiliza para escenarios donde se
requiera un alto throughput, así como bajos tiempo de
QoS 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.
% servicio activo
Disponibilidad
Comentario
Depende de situaciones ajenas al funcionamiento del
sistema.
Disponibilidad Tolerancia a Fallas X x
Comentario
Ambos presentan algoritmos que los hacen tolerantes a
fallas.
Recuperación ante fallas X X
Confiabilidad X X
32
Comentario
Un sistema SAN posee una mayor velocidad para
recuperarse ante una falla lo que hace que sea un sistema
confiable. Una NAS presenta la limitante que depende del
throughput de la red a la cual esté conectada.
Usuario Final
Administradores
Usabilidad Comentario
No depende de la Arquitectura sino de la solución de
software del SA.
Comentario
Robustez Este aspecto no indica superioridad de uno sobre otro
depende del proveedor de la solución elegido.
Factibilidad
Costos en general X X
Factibilidad
Económica Comentario
Un sistema SAN es mucho más costoso por todo el
equipamiento que este requiere. Por su parte una NAS es
una solución mucho más económica la cual puede ser
implementada hasta para uso doméstico.
Comentario
Seguridad Depende de las políticas que desee implementar el cliente
no del sistema en sí.
1.7.4 Tipos de Infraestructuras más empleadas en SA.

Redes de Almacenamiento No Convergente. [95]
Este tipo de infraestructura es empleada en las SANs tradicionales. En este tipo de

infraestructura la red de almacenamiento está totalmente aislada de la red ethernet. Este tipo
de infraestructura utiliza cables de fibra óptica para la transmisión de datos entre los servidores
que constituyen el clúster de almacenamiento. Esto implica que es necesario switches y routers
que soporten FC además de las interfaces de red de los servidores. Adicionalmente este tipo
de solución en su mayoría son propietarias y vienen con su propio software para la gestión.
No hay dudas que una red de canal de fibra es una red muy rápida aislada normalmente del
tráfico de la red LAN de la empresa. Sin embargo, es muy cara. Las tarjetas de canal de fibra
óptica cuestan alrededor de mil dólares cada una. También requieren adaptadores llamados
(HBAs) para poder convertir de FC a Ethernet. Cada HBA tiene un nombre único mundial
(WWN), que es similar a la MAC de Ethernet ya que se usa un identificador único organizado,
asignado por el IEEE.
Dada la evolución de las redes ethernet hasta 40Gbps y la existencia de los discos de estado
sólido (SSD) con velocidades de escritura y lectura en el orden de los gigabits las redes no
33
convergentes de almacenamiento (FC) poco a poco están pasando a un segundo plano y las
empresas poco a poco están migrando poco a poco a redes convergentes que pueden ofrecer
en estos momentos un desempeño muy similar a FC y a un costo mucho menor.
Redes de Almacenamiento Convergentes. [96] [97]
La comunicación en redes se realiza normalmente a través de Ethernet con tráfico de

almacenamiento mediante un entorno de canal de fibra SAN. Es común tener una red dedicada
o enlace de serie para administración de sistemas y como resultado, un servidor único suele
estar en múltiples redes. Las conexiones múltiples en cada servicio son costosas, voluminosas y
complejas de manejar. Esto da lugar a la necesidad de consolidar todas las conexiones en una.
El Canal de fibra en Ethernet (FCoE) y el Sistema de Interfaz para computadoras pequeñas en
Internet (iSCSI) responden a esta necesidad.
FCoE
Con los comandos de FCoE, los comandos de canal de fibra estándar y los paquetes de datos se
transportan en una infraestructura física 10GbE a través de una sola tarjeta de red convergente
(CNA). El tráfico de Ethernet estándar TCP/IP y las operaciones de almacenamiento de canal de
fibra se pueden transportar a través del mismo enlace. FCoE usa una tarjeta de interfaz de red
física (y un cable) para múltiples conexiones lógicas de almacenamiento y red. Es decir que FcoE
permite una red convergente para llevar tráfico IP y FC, combinando la funcionalidad de una
LAN y una SAN. Muchos centros de datos modernos utilizan redes LAN y SAN convergentes
trabajando juntas como se muestra en la Figura 15
Figura 15 Ejemplo de Red Convergente
FCoE tiene las siguientes ventajas:
Número reducido de conexiones: FCoE reduce a la mitad el número de conexiones de red a un

servidor. Usted puede tener múltiples conexiones para rendimiento o disponibilidad; sin
embargo, una sola conexión proporciona conexión de almacenamiento y redes. Esto es muy útil
34
para servidor de caja de pizza y servidor de cuchilla, ya que ambos tienen espacio muy limitado
para componentes.
Menor costo: El número reducido de conexiones significa una reducción de cables, interruptores
y otro equipo de redes. La historia de Ethernet también presenta grandes economías de escala;
el costo de redes cae de forma dramática cuando la cantidad de dispositivos en el mercado pasa
de millones a mil millones, como se vio declinar el precio de dispositivos de Ethernet de 100Mb
y Ethernet de gigabits.
Igualmente, 10GbE serán más baratos cuando más negocios adapten su uso. Puesto que el
hardware de CNA se integra en un solo chip, el uso extendido también aumentará su volumen
en el mercado, lo cual se traducirá en una caída de precio significativa con el tiempo.
iSCSI
Internet SCSI (iSCSI) es otro tipo de protocolo de red convergente; es una alternativa para FCoE.
Al igual que canal de fibra, iSCSI proporciona almacenamiento de nivel de bloques en una red.
Sin embargo, iSCSI no proporciona una administración total del entorno. La ventaja principal
sobre iSCSI en FCoE es que iSCSI proporciona mucha de la habilidad y flexibilidad de canal de
fibra, pero a un bajo costo.
Almacenamiento Definido por Software [98]
Se ha propuesto el almacenamiento definido por software (SDS) (aproximadamente en 2013)

como una nueva categoría de productos de software de almacenamiento. SDS puede ser un
elemento dentro de un Software Defined Data Center, pero también puede funcionar como una
tecnología independiente. El término Software Defined Storage es una palabra clave de
marketing que es una continuación del término Software Defined Networking, que se utilizó por
primera vez para describir un enfoque en la tecnología de red que abstrae varios elementos de
la red y crea una capa de abstracción o virtualizada en software.
Las capacidades de red ahora están poniéndose al día con las capacidades que se han ofrecido
en la industria del almacenamiento durante más de una década. SDS representa una nueva
evolución para la industria del almacenamiento en cuanto a cómo se administrará y desplegará
el almacenamiento en el futuro.
Los siguientes son atributos de SDS que normalmente se ven en el mercado:
a) Puede permitir a los clientes "construirlo ellos mismos", proporcionando su propio

hardware para crear una solución con el software proporcionado.
b) Puede funcionar con hardware arbitrario o también puede mejorar las funciones
existentes de hardware especializado.
c) Casi siempre permite la escala de almacenamiento (no sólo la escala típica de grandes
cajas de almacenamiento).
35
d) Casi siempre incluye la agrupación de almacenamiento y otros recursos.

e) Puede permitir la construcción de la "solución" de almacenamiento y datos de forma
incremental.
f) Incorpora la automatización de la gestión.
g) Incluye una interfaz de autoservicio para los usuarios.
h) Incluye una forma de gestión de nivel de servicio que permite el etiquetado de
metadatos para impulsar el tipo de almacenamiento y servicios de datos aplicados. La
granularidad puede ser grande para comenzar, pero se espera que se mueva a una
capacidad de nivel de servicio de grano más fino con el tiempo.
i) Permite a los administradores establecer una política para administrar los servicios de
almacenamiento y datos.
SDS prefiere una interfaz de gestión de almacenamiento estandarizada (como SMI-S) con el fin
de automatizar la gestión de los recursos de almacenamiento y descubrir sus capacidades para
su uso en diversos pools. SMI-S, es un estándar de almacenamiento desarrollado y mantenido
por la Storage Networking Industry Association (SNIA). También ha sido ratificado como una
norma ISO [99]. SMI se basa en el modelo de información común y los estándares de gestión
empresarial basados en Web definidos por el grupo de trabajo de administración distribuida,
que definen la funcionalidad de gestión a través de HTTP. La versión aprobada más reciente de
SMI-S está disponible en el SNIA [100].
El objetivo principal de SMI-S es permitir una gestión interoperable amplia de sistemas de

proveedores de almacenamiento heterogéneos. La versión actual es SMI-S V1.6.0. Más de 75
productos de software y más de 800 productos de hardware están certificados como conformes
a SMI-S.
Sin embargo, las interfaces de gestión de almacenamiento heredadas son comunes hoy en día,
y predecir su desaparición es prematuro. Además, hay emergentes API de código abierto que
se están convirtiendo en un estándar de gestión de almacenamiento de facto, un ejemplo es
OpenStack Cinder.
Por último, SDS permite a los administradores trabajar con interfaces abstractas que les
permiten gestionar agrupaciones, asignar nuevos recursos, configurar políticas y determinar los
niveles de servicio. Otras características pueden ser consultadas en el ANEXO I.
1.7.5 Comparación entre las principales soluciones SLCA para SA.

Luego de conocer la arquitectura del SA es necesario la elección del software que pueda
implementarla y que pueda responder a los RNF descritos con anterioridad en el capítulo 1.5.
Con este objetivo se realizó un estudio para conocer cuáles son las principales soluciones más
utilizadas específicamente abogando por aquellas que son SLCA. El estudio se basó en los más
empleados por la comunidad Linux y en artículos de la academia donde realizan comparativas
36
entre dichos sistemas [101] [102] [103] [104] [105] [106] . El resultado de la investigación dio a
conocer que los más utilizados fueron de manera general HDFS, Ceph, GlusterFS, iRODS y Lustre
aunque hay otros como QuantcastFS, XtreemFS, MooseFS , PVFS y BeeGFS que también son
utilizados pero en menor medida que los anteriores según los artículos citados y la búsqueda
realizada hasta este momento.
A continuación, se presenta una comparación entre las diferentes soluciones. En el Anexo C se

encuentran los conceptos básicos para una mayor compresión de estos sistemas y en el Anexo
D el análisis de los más utilizados de forma particular.
Resultados
Después del estudio de los conceptos básicos que presentan estos sistemas, en teoría, las
arquitecturas descentralizadas parecen escalar mejor que las centralizadas gracias a la gestión
de la carga de trabajo distribuida. Además, la elección de una solución u otra se debe hacer de
acuerdo al uso que se le desee dar. Para obtener rendimiento, replicación asíncrona y el uso de
un único índice para mantener el espacio de nombres, son preferibles arquitecturas
centralizadas mientras que una arquitectura descentralizada es mejor para la gestión de
grandes cantidades de datos y peticiones.
En cuanto a la tolerancia a fallos, se pudo ver que todos, excepto Lustre, detectan el fallo de un
servidor y ponen el mismo en cuarentena de forma transparente para el usuario. También fue
identificada la habilidad de estos para mantener un número de réplicas deseado en aras de
proveer la redundancia necesaria en caso de fallos de lo cual Ceph y GlusterFS son líderes a la
hora de su recuperación.
La escalabilidad es la capacidad del sistema para, sin perturbar su rendimiento, crecer haciendo
frente a un número cada vez mayor de clientes que realizan solicitudes y operaciones de E/S y
también almacenar un número cada vez mayor de archivos de distintos tamaños. En este
ámbito, gracias a que GlusterFS y Ceph no presentan una estructura centralizada en cuanto a
los servidores de metadatos, como los restantes DFS, estos pueden afrontar un gran número
de peticiones de clientes, siendo Ceph el que mejor desempeño presenta en este sentido ya
que distribuye la gestión de metadatos a través de varios servidores de metadatos. Sin embargo,
al tener separada la gestión de los metadatos de la gestión de los datos, con Ceph se requiere
añadir dos tipos de servidores: de metadatos y de datos, lo que lo hace un sistema más complejo
de escalar comparado con GlusterFS.
Se pudo comprobar que HDFS, QFS, PVFS, MooseFS, iRODS y Lustre son más adecuados para
almacenar pequeñas cantidades de grandes archivos mientras que Ceph y GlusterFS son
adecuados para manejar archivos grandes y pequeños. Ceph empeora su desempeño a la hora
de replicar los archivos, debido quizás a la replicación sincrónica, no siendo así para el resto de
los DFS, de los cuales en cuanto a escritura GlusterFS sin dudas es el de mejor desempeño. Sin
37
embargo, [106] afirma que en una prueba de desempeño de E/S aplicada a Ceph, PVFS, Lustre
y BeeGFS, se obtiene que Ceph tiene el mejores resultados.
Se pudo observar que tanto Ceph como GlusterFS utilizan un algoritmo para calcular la
localización de los archivos, lo que reduce la carga de trabajo de los servidores de metadatos,
ya que con esta variante son los clientes los que realizan la búsqueda de los archivos a partir de
los datos brindados por los servidores de metadatos, lo que representa una ventaja frente al
método utilizado por el resto de las soluciones.
En cuanto a la detección de fallas todos excepto Lustre, PVFS y QFS, presentan fuertes
mecanismos para la detección de fallas, gracias a que los servidores están totalmente
conectados e intercambian mensajes para estos fines.
Ceph y GlusterFS presentan una alta disponibilidad gracias a que los metadatos están replicados
y su gestión se distribuye entre varios servidores, contrariamente a un sistema centralizado
(como el caso del resto de los DFS), donde los servidores de metadatos representan un punto
único de fallo, que puede causar la pérdida de metadatos y la indisponibilidad del sistema.
Aunque estos últimos implementan mecanismos para resolver este problema, es evidente la
superioridad de Ceph y GlusterFS sobre estos en cuanto a la disponibilidad.
Como la caída de un servidor puede provocar la inaccesibilidad de los datos se utiliza el método
de la replicación, con el cual se realizan varias copias de los datos asegurando la disponibilidad
e introduciendo un problema de coherencia que necesita de sincronización en aras de ser
resuelto. En cuanto a la disponibilidad de los datos, Ceph y QFS almacenan automáticamente
réplicas en bastidores diferentes, verifican automáticamente si la replicación ocurrió de forma
satisfactoria, remueven las mismas cuando no es el caso y utilizan replicación sincrónica (que
provoca inaccesibilidad de los datos durante la ocurrencia de la misma) y en el caso de QFS
también asincrónica. Siendo Ceph y QFS los únicos de los analizados que cuentan con las
características antes mencionadas, es evidente su superioridad con respecto al resto en este
aspecto.
Mientras Ceph y GlusterFS cuentan con algoritmos que distribuyen la carga de trabajo de
metadatos y permiten agregar dinámicamente nuevos servidores, el servidor de metadatos
único de los sistemas centralizados, como es el caso del resto, representa un cuello de botella.
La sobrecarga de los servidores de datos puede provocar que estos tengan que enfrentar más
operaciones de E/S conduciendo así a una congestión en la red. HDFS, QFS, Ceph y GlusterFS
logran resolver este problema mediante la ubicación de los datos de acuerdo con el espacio
libre en cada disco y moviendo datos de servidores sobrecargados a otros no tanto. Aunque
esta última ventaja debe ser realizada de forma manual, no es el caso de QFS, y no automática
como la primera, es apreciable como estos presentan una clara ventaja con respecto al resto.
38
Otro aspecto importante a tener en cuenta en la comparación, es determinar el nivel de

abstracción y se puede ver que aquellos que están basados en objetos presentan una clara
ventaja sobre los que no, ya que esto les permite alcanzar un alto desempeño. De los analizados,
Ceph, PVFS, PNFS, XtreemFS y Lustre son los que pueden trabajar en el nivel de abstracción de
objetos.
En cuanto al soporte por parte de los principales GN se tomó una muestra y se analizaron los
siguientes: OpenStack, VMware, Microsoft, CloudStack, Proxmox y Opennebula. En todos ellos
se puede verificar que los factores comunes son Ceph y GlusterFS [107] [108] [109] [110] [111]
[112] [113] lo que es muy importante ya que demuestra el interés de estos proveedores en
estas soluciones y además las reafirman como una elección por encima de las anteriores
analizadas.
En la Tabla 11 se muestra a modo de resumen lo planteado e información adicional que no fue

tratada hasta este punto y puede ser de interés principalmente en los que son más utilizados
(HDFS, Ceph, GlusterFS, iRODS y Lustre). Toda la información mostrada a continuación es
extraída de las páginas web de cada uno de las soluciones tratadas con anterioridad.
Tabla 11 Tabla Resumen de la comparación entre los principales DFS.
HDFS GlusterFS Ceph iRODS Lustre

Centralizad Descentraliza Distribuid Centralizad Centralizad
Arquitectura
a da a a a
CLI, FUSE, FUSE, CLI, FUSE,
API FUSE FUSE
REST, API REST API
Detección/Correcci Automátic Automátic
Detección P2P Manual
ón de Fallas a a
Disponibilidad del
Alta Alta Alta Alta Fallas
sistema
Redundancia de Replicació
Replicación Tipo RAID Replicación No
Datos n
Estrategia de
Automátic Automátic
colocación de la Manual Manual No
a a
información
Asincrónic
Replicación Sincrónica Sincrónica Sincrónica Tipo RAID
a
Consistencia de la WORM,
No Bloqueos Bloqueos Bloqueos
caché lease
Automátic Automátic
Balance de carga Manual Manual No
o o
Lenguaje Java C C C C
Apache
Licencia GPL v2/v3 LGPL BSD GPLv2
License 2.0
Soporte Si Si Si Si Si
39
Medio a Medio a
Hardware12 Medio Medio -
Alto alto
Estado En uso En uso En uso En uso En uso
Conclusión
Luego de analizadas las principales soluciones SLCA para SA se llegó a la conclusión de que
evidentemente Ceph y GlusterFS son los que más destacan. Por ello, el autor las propone como
solución, Ceph para una SAN y GlusterFS para NAS. Un desglose de sus principales
funcionalidades (RF) se encuentran en el ANEXO M.
1.7.6 Conclusiones parciales

En base a lo tratado en los Epígrafes 1.7-1.7.4 el autor propone el esquema mostrado en la
Figura 16 que facilitará la elección de un sistema u otro. En este esquema se refleja la propuesta
por la cual el autor aboga y tiene en cuenta tanto la arquitectura, la solución de software, el tipo
de almacenamiento, la misión y el tipo de infraestructura a utilizar a la hora de desplegar un SA.
Figura 16 Resumen elección del SA
12
La columna Hardware muestra en qué medida son necesarios los recursos de cómputo, siendo el parámetro
“medio” otorgado en dicha columna 4GB de RAM y CPU con dos núcleos
40
En primer lugar, se aboga por una infraestructura de red convergente dado el ancho de banda
que actualmente presentan las redes ethernet además de abaratar los costos tanto del
cableado, como de los dispositivos de interconexión y servidores.
El autor aboga por utilizar una SAN en escenarios donde existan máquinas virtuales y
aplicaciones de alto throughput como bases de datos y páginas web, utilizado bloques y objetos
respectivamente y propone como solución de software a Ceph por las ventajas antes
mencionadas (Epígrafe 1.7.5).
En cuanto a una NAS se aboga su utilización para las Salvas y para el almacenamiento de
información variada tales como documentos, fotos, videos con el objetivo de brindar DSaaS.
Para ello se propone como solución a GlusterFS.
1.8. Tipos de Discos para SA [25].
El tipo de discos duros en el servidor host o en la matriz de almacenamiento que utilizan los
servidores de archivos tiene un impacto significativo en el rendimiento general de la
arquitectura de almacenamiento. Los factores de rendimiento críticos para los discos duros son:
 La arquitectura de la interfaz (por ejemplo, SAS o SATA)

 La velocidad de rotación de la unidad (por ejemplo, 10K o 15K RPM) o una unidad de
estado sólido (SSD) que no tiene partes móviles
 La velocidad de lectura y escritura
 La latencia media en milisegundos (ms)
La Tabla 12 muestra un resumen de las principales características de las interfaces de

almacenamiento actuales:
Tabla 12 Características de las interfaces de almacenamiento actuales
Características FC SATA SCSI SAS

6 Gbps Menor de 6 Gbps (SAS-
Razón de datos 10 Gbps
(SATA III) 2.5 Gbps 2)
Costo Alto Bajo Medio Medio
Capacidad de los discos
Media-Alta Alta Media-Alta Baja
asociados
30 m (par de
Menor de
Distancia máxima sin cobre) 1 m (par de 8 m (par de
25 m (par de
pérdidas 10 km (Fibra cobre) cobre)
cobre)
Óptica)
Desempeño Alto Bajo-Medio Medio Medio-Alto
Esquema de transmisión Serie Serie Paralelo Serie
41
Otros factores, como la caché de la unidad y el soporte para funciones avanzadas, como NCQ,
TRIM (SATA solamente), Commanded Command Queuing y UNMAP (SAS y Fibre Channel)
pueden mejorar el rendimiento y la duración.
Al igual que con la conectividad de almacenamiento, las altas operaciones de E / S por segundo
(IOPS) y baja latencia son más críticas que el rendimiento máximo sostenido cuando se trata de
dimensionar y el rendimiento de los clientes en el servidor. Esto se traduce en la selección de
unidades que tienen la mayor velocidad de rotación y la menor latencia posible, y la elección de
cuándo utilizar SSD para un rendimiento extremo. En cuanto a ello [114] [115] [116] [117]
muestran los umbrales que se consideran aceptables en cuanto a las latencias de los diferentes
tipos de discos, donde para un HDD las latencias rondan los 15-20 ms aproximadamente y para
un SSD pueden llegar hasta los 5ms. Es necesario señalar que esas son las latencias que
normalmente presentan estos tipos de discos, pero en las referencias citadas no se tomó en
cuenta los tamaños de bloques por lo cual estos umbrales pueden variar.
1.8.1 Serial ATA (SATA)

Las unidades Serial ATA (SATA) son una opción de bajo costo y relativamente alto rendimiento
para el almacenamiento. Las unidades SATA están disponibles principalmente en los estándares
de 3 Gbps y 6 Gbps (SATA II y SATA III), con una velocidad de rotación de 7.200 RPM y latencia
promedio de alrededor de cuatro milisegundos. Normalmente, las unidades SATA no están
diseñadas para cumplir con los estándares de fiabilidad de nivel empresarial, aunque las nuevas
tecnologías pueden ayudar a que las unidades SATA sean una opción viable para escenarios de
un solo servidor. Sin embargo, los discos SAS son necesarios para todos los escenarios de clúster
y alta disponibilidad que utilizan espacios de almacenamiento.
1.8.2 SAS
Las unidades SCSI (SAS) conectadas en serie suelen ser más caras que las unidades SATA, pero
pueden proporcionar un rendimiento superior en el rendimiento y, lo que es más importante,
una baja latencia. Las unidades SAS normalmente tienen una velocidad de rotación de 10K o
15K RPM con una latencia promedio de 2ms a 3ms e interfaces de 6 Gbps. También hay SAS
SSDs. A diferencia de las unidades SATA, las unidades SAS tienen puertos de interfaz dual que
se requieren para el uso de espacios de almacenamiento agrupados.
La mayoría de las matrices SAN actualmente utilizan unidades SAS; Pero algunas matrices de
extremo superior también utilizan Fibre Channel, unidades SAS y unidades SATA. Por ejemplo,
las unidades SAS se utilizan en el patrón de Infraestructura Definida por Software junto con un
recinto de almacenamiento JBOD, que habilita la función Espacios de almacenamiento.
1.8.3 Nearline SAS (NL-SAS)

Las unidades SAS de Nearline (NL-SAS) ofrecen las mayores ventajas de la capacidad de las
unidades SATA empresariales con una interfaz SAS totalmente capaz. Las propiedades físicas de
la unidad son idénticas a las de las unidades SATA tradicionales, con una velocidad de rotación
42
de 7.200 RPM y una latencia promedio de alrededor de cuatro milisegundos. Sin embargo,
exponer la unidad SATA a través de una interfaz SAS proporciona todas las características
empresariales que vienen con una unidad SAS, incluyendo múltiples soportes de host, canales
de datos concurrentes, rutas redundantes a la matriz de discos (requerida para espacios de
almacenamiento agrupados) y colas de comandos empresariales. El resultado son unidades SAS
que son capaces de capacidades mucho mayores y disponibles a costos significativamente más
bajos.
Es importante tener en cuenta que, aunque las unidades NL-SAS proporcionan mayor capacidad
a través de la interfaz SAS, tienen la misma latencia, confiabilidad y limitaciones de rendimiento
de las unidades SATA empresariales tradicionales, lo que resulta en mayores índices de fallas de
unidades SATA en comparación con las unidades nativas SAS.
Como resultado, las unidades NL-SAS se pueden utilizar en escenarios de clúster y alta
disponibilidad que utilizan Espacios de almacenamiento, aunque se recomienda
encarecidamente utilizar unidades SSD para implementar niveles de almacenamiento para
mejorar el rendimiento del almacenamiento.
1.8.4 Canal de Fibra

Fiber Channel se utiliza tradicionalmente en matrices SAN y proporciona alta velocidad (igual
que SAS), baja latencia y confiabilidad a nivel empresarial. Fibre Channel suele ser más caro que
el uso de unidades SATA o SAS. Fibre Channel normalmente tiene características de rendimiento
similares a las de las unidades SAS, pero utiliza una interfaz diferente. La elección de las unidades
Fibre Channel o SAS suele estar determinada por la elección de la matriz de almacenamiento o
la bandeja de la unidad. En muchos casos, los SSD también se pueden utilizar en matrices SAN
que utilizan interfaces Fibre Channel. Todas las matrices también admiten dispositivos SATA, a
veces con un adaptador. Los vendedores de discos y de matrices han pasado en gran medida a
unidades SAS.
1.8.5 Discos de Estado Sólido

SATA, SAS, NL-SAS y Fibre Channel describen el tipo de interfaz, y una unidad de estado sólido
(SSD) se refiere a la clasificación del tipo de medio. El almacenamiento en estado sólido tiene
varias ventajas sobre los discos de medios de hilatura tradicionales, pero tiene un costo
premium. El tipo más frecuente de almacenamiento en estado sólido es una unidad de estado
sólido. Algunas ventajas incluyen una latencia significativamente menor, sin tiempo de
centrifugado, velocidades de transferencia más rápidas, menores requerimientos de energía y
enfriamiento, y sin preocupaciones de fragmentación.
Los últimos años han demostrado una mayor adopción de SSDs en los mercados de
almacenamiento de empresas. Estos dispositivos más caros suelen reservarse para cargas de
trabajo que tienen requisitos de alto rendimiento. La mezcla de SSD con discos giratorios en
matrices de almacenamiento es común para minimizar el costo. Estas matrices de
43
almacenamiento suelen tener algoritmos de software que colocan automáticamente los

bloques de almacenamiento de acceso frecuente en los SSD y los bloques de acceso menos
frecuente en los discos de menor coste (denominados niveles automáticos), aunque la
segregación manual de agrupaciones de discos también es aceptable. La memoria flash NAND
se utiliza más comúnmente en los SSD para almacenamiento empresarial.
1.8.6 Discos Híbridos

Las unidades híbridas combinan discos giratorios tradicionales con memoria no volátil o
pequeños SSD que actúan como un buffer grande. Este método proporciona los beneficios
potenciales del almacenamiento en estado sólido con la rentabilidad de los discos
tradicionales. Actualmente, estas unidades no se encuentran comúnmente en las matrices de
almacenamiento empresarial.
1.9. Pruebas para caracterizar y evaluar sistemas de almacenamiento

Para garantizar que los Sistemas de Almacenamiento empleados ofrezcan elevados niveles de
disponibilidad, seguridad, desempeño, así como otros requerimientos técnicos que aseguran la
calidad de los servicios de datos, es imprescindible definir un conjunto de pruebas de validación,
que permitan tener el control sobre las características funcionales y operativas de estos
sistemas y que certifiquen sus capacidades reales. Actualmente esto no existe de manera formal
y única, sino que cada fabricante o proveedor propone pruebas de validación que se ajustan a
su equipamiento y tecnologías. Otras organizaciones en cambio, limitan su alcance a
determinadas categorías como disponibilidad o desempeño [118].
Para conocer las pruebas que actualmente se utilizan se analizaron varias fuentes de
importancia internacional entre ellas las recomendaciones de organizaciones de
estandarización como el Instituto Nacional de Estándar y Tecnología (NIST), la Unión
Internacional de Telecomunicaciones (UIT), la Distributed Management TaskForce (DMTF) y la
Asociación de Industrias del Almacenamiento en Red (SNIA) [119] [56], [57] [122] [123] [124]
También se analizaron unos de los principales proveedores de Nube Amazon [125], y Microsoft
[126], para conocer las pruebas a las que ellos sometían su infraestructura Nube.
De lo anterior se pudo conocer que Amazon, una de las grandes entidades que posee Nubes
para brindar IaaS, ha realizado algunas pruebas de desempeño a su Nube Amazon Elastic
Compute Cloud (Amazon EC2) basándose en los métodos y las métricas definidas en las
siguientes benchmarks: LMbench, Bonnie, CacheBench y HPC ChallengeBenchmark [61], pero
todas las pruebas estuvieron basadas en las cinco instancias del entorno de Amazon EC2
(m1.small, m1.large, m1.xlarge, c1.medium y c1.xlarge) como bien se describe en el documento
referenciado, lo cual indica que esto no constituye un estándar para métricas ni para evaluación
de desempeño de sistemas, de hecho se conoce que en otras Nubes que brindan IaaS como
GoGrid, Mosso y ElasticHost (EH) no emplean las mismas benchmarks para sus pruebas de
desempeño. Por otro lado, la compañía Microsoft ha publicado un conjunto de pruebas de
44
validación para Sistemas de Almacenamiento que soportan clústeres de conmutación por error
[62], las cuales tienen un perfil bastante general, aplicables a una gran variedad de Sistemas de
Almacenamiento, pero tampoco constituyen un estándar [127]. Por su parte, a pesar de los
avances realizados, las organizaciones de estandarización como la SNIA, la UIT y el NIST, no han
obtenido un conjunto de pruebas de validación estandarizadas para evaluar las potencialidades
de los Sistemas de Almacenamiento en general.
En base a lo anterior el autor del presente trabajo propone el conjunto de pruebas de validación
definidas en [118] la que se pueden observar en la Tabla 13 y la que según sus autores están
basadas en las pruebas que realizan los principales proveedores de servicios Nube. No se
identificó una prueba para medir la eficiencia por lo cual el autor propondrá la empleada en
[38] con métricas obtenidas en [128] [129].
Tabla 13 Propuesta de pruebas para evaluar SA.
Nombre de la prueba
Categorías Subcategorías Descripción
propuesta
Las pruebas propuestas bajo

esta categoría quedan
PRUEBAS DE
respaldadas por su importancia a
ESTADO DE Monitorización
la hora de conocer los niveles de
UTILIZACIÓN
utilización de las capacidades del
sistema.

respaldadas por su importancia
a la hora de conocer cómo se
desempeña un Sistema de
Exposición del Sistema Almacenamiento bajo una carga
PRUEBAS DE
de Almacenamiento a de trabajo extrema, lo cual es
ESTRÉS
tareas exhaustivas cada vez más común en
Sistemas de Almacenamiento
para servicios telemáticos en la
actualidad, con la creciente
demanda sobre los sistemas
computacionales.
Validación de las Las pruebas propuestas bajo

transferencias de esta categoría quedan
datos respaldadas por su importancia
a la hora de conocer cuán rápida
PRUEBAS DE es transferida una determinada
TRANSFERENCIA Validación de la carga de datos hacia o desde un
precisión de las Sistema de Almacenamiento de
PRUEBAS DE transferencias forma exitosa, lo cual da una
DESEMPEÑO clarísima idea de su rendimiento
y de la Calidad del Servicio (QoS).
45

a la hora de conocer cuán rápido
son procesadas las peticiones al
PRUEBAS DE Validación de los
Sistema de Almacenamiento.
DEMORAS tiempos de respuestas
Además esta constituye uno de
los pilares fundamentales para
dar una idea de la QoS que
brinda el Sistema de
Almacenamiento.
Validación de las Las pruebas propuestas bajo esta

operaciones de categoría quedan respaldadas por
lectura su importancia a la hora de
conocer cuán rápido se suceden
PRUEBAS DE L/E
Validación de las las peticiones exitosas de L/E en
operaciones de el Sistema de Almacenamiento, lo
escritura cual tiene influencia directa en el
rendimiento.

Validación de la
a la hora de conocer cuánto se
PRUEBAS DE ESCALABILIDAD persistencia del
afecta el desempeño del
rendimiento
sistema al aumentar el número
de usuarios que reciben el
servicio.

Validación de la
PRUEBAS DE DISPONIBILIDAD para garantizar que los datos
disponibilidad
estén disponibles para los
usuarios aun cuando ocurran
fallos en el sistema.

Validación de los para verificar los procesos de
PRUEBAS DE CONFIGURACIÓN procesos de creación, configuración y
configuración eliminación de recursos
virtuales.
46
1.10. DSaaS. Principales soluciones SLCA.

Una de los servicios que puede brindar una pequeña o mediana empresa a sus empleados es
un servicio de almacenamiento de datos. Es aquí donde el usuario puede subir sus documentos
personales y tener salvas de su información más importante. Además, este tipo de servicio
permite compartir información con otros usuarios mediante un enlace permanente al archivo.
Dada la gran utilidad que presenta este servicio en las SMB se hace necesario un estudio de
aquellas soluciones SLCA que permitan desplegarlo, en este caso prestando una mayor
importancia al tema de la usabilidad ya que esta aplicación tendrá un impacto directo sobre el
usuario final.
Para ello se realizó una búsqueda para identificar cuáles eran las más utilizadas por la
comunidad. Ya que la naturaleza del software es Código Abierto, no se identificó ninguna
consultora de prestigio que tuviera rankings con respecto a ellas. Es por ello que la elección de
estos softwares se basó principalmente en los RF que cada una podía ofrecer al usuario, la
usabilidad que presentaba y qué instituciones las estaban implementando.
La investigación dio como resultado que las más usadas son: OwnCloud, Seafile y Pydio.
Owncloud [130]
Owncloud fue la que más consumidores presentó con más de 100 organizaciones de las cuales
aproximadamente el 45% son centros de estudios universitarios. Presenta una buena usabilidad
para los usuarios finales y ofrece un sitio web con una demo de la aplicación antes de
descargarla. En cuanto a sus RF cubre la mayoría de las operaciones básicas que desea un
usuario como subir, bajar, borrar y compartir información. Un desglose de todos los RF que
permite Owncloud se encuentran en el ANEXO K. Además, posee addons los cuales le pueden
brindar funcionalidades adicionales como calendario o reproductor de música. También
permite la sincronización de la información entre dispositivos móviles y la PC con la aplicación.
Seafile [131]
Otra buena plataforma de DSaaS. Según el sitio oficial presentan clientes tanto en Alemania,
Francia, Finlandia, Estados Unidos, Canadá, Rusia, Polonia y China. La usabilidad es bastante
buena y como Owncloud posee una web demo para probar sus prestaciones. Además de ofrecer
las funcionalidades básicas ofrece otras muy interesantes no presentes en Owncloud como
establecer permisos específicos a cada carpeta aumentando así la seguridad de la información
ya que evita la eliminación por equivocación. Un desglose de todos los RF que permite SeaFile
se encuentran en el ANEXO K. Como el anterior permite la sincronización de la información
entre dispositivos móviles y el pc con la aplicación.
47
Pydio [132]
Por último, se encuentra Pydio y es esta plataforma la que el autor propone. Según el sitio oficial
es utilizada por prestigiosas universidades como la Universidad de Cambridge y la Universidad
de Washington; además por grandes compañías como Seagate y Nikon. La usabilidad a
consideración del autor es excelente y ofrece como distinción aspectos como un tour de inicio
al usuario donde poco a poco le explica cada funcionalidad a medida que la quiera utilizar.
También la forma de gestión de los archivos es diferentes ya que es muy similar a la de un SO
personal permitiendo dar click derecho y desplegándose la cinta de opciones. Posee nuevas
funcionalidades como compresión de archivos y un editor de OpenOffice integrado lo que
permite la edición de documentos personales en cualquier lugar. En suma a lo anterior posee
una libreta de contactos, un reproductor de medios y además realiza todas las operaciones
básicas de archivos. Como los anteriores posee un demo donde el usuario puede probar la
plataforma antes de adquirirla. Un desglose de todos los RF que permite Pydio se encuentran
en el ANEXO K. Como en los casos anteriores permite la sincronización de la información entre
dispositivos móviles y el pc con la aplicación.
1.11. Sistema de Salvas. Principales soluciones SLCA.

Luego de tener nuestro SA implementado ese hace necesario contar con un sistema de salvas
para resguardar la información. El valor de nuestra información muchas veces supera el costo
del equipo, es por eso, que se recomienda que en un CD se mantenga un backup o respaldo de
la información periódicamente. El valor material que tiene el equipo es cuantificable, sin
embargo, nuestra información y el tiempo que invertimos en ella tienen un gran precio. Más
aun cuando, perder información significa no solo tiempo, sino que también logramos el
descontento de los clientes a los cuales damos servicio.
Como recomendación, se sugiere al menos tener una salva de cada servicio importante de la
empresa. Con esto se tiene la posibilidad de volver a instalar el servicio en cuestión de minutos
en caso de que ocurra algún suceso inesperado.
Para disminuir errores se debe realizar con profesionalismo, conocimiento, y utilizando las
técnicas y dispositivos adecuados junto a una buena solución de respaldo. Para ello se realizó
una investigación con el objetivo de conocer cuáles son las principales soluciones SLCA que
permiten cumplir este objetivo.
Se pudo identificar que las más utilizadas de forma general son Bácula y Amanda Backup [133].
Ambas son soluciones muy utilizadas y ambas poseen RF parecidos. Además, ambas tienen un
roadmap excelente que como promedio se puede identificar que presentan una nueva versión
cada año. Ambas poseen gran soporte de sistemas operativos, tanto propietarios como
privados.
Ambas son soluciones excelentes pero el autor propone a Bácula ya que esta posee, a diferencia
de Amanda Backup, una mejor documentación, un mejor soporte y una mejor usabilidad ya que
48
cuenta con una interfaz web mucho más amigable al usuario. Además, a diferencia de Amanda
Backup, Bácula es empleada por centros de gran prestigio internacional según su sitio web tales
como: NASA, Banco de Austria, Universidad de Texas, Universidad Leibniz de Hannover, entre
otras [134]. Un resumen de los RF tanto de Amanda Backup como Bácula puede encontrarse en
el ANEXO L
1.12. Conclusiones
El análisis realizado a los métodos planteados por las diferentes instituciones revela los puntos
comunes que tienen las grandes compañías, así como sus deficiencias a la hora de realizar un
diseño con la filosofía del top-down enfocada al SA. En los casos estudiados se destacó la
ausencia de información y criterios para elaborar pruebas para medir diferentes variables que
permitan crear un criterio cualitativo y cuantitativo del SA en CD privados. También que en casi
ninguno se tiene en cuenta los requerimientos específicos de cada institución, sino que
proponen un diseño genérico no dimensionado.
En suma, a lo anterior el estudio de las diferentes arquitecturas y su comparación con la de la

NP brinda un enfoque general de las capas que no deben faltar, así como los dispositivos a la
hora de construir un SA óptimo. También el estudio de los tipos de SA más utilizados en CD
permitió comprender las ventajas y desventajas de uno sobre otro y brinda los aspectos
esenciales a la hora de escoger uno u otro, así como la solución que lo sustente. A la vez una
correcta elección de los discos y las interfaces de almacenamiento permite que el sistema
responda de manera eficiente a los RNF mencionados anteriormente.
Todo la anterior expuesto sentó las bases para elaborar un método para el diseño de SA acorde
con los principios de la filosofía top-down, tomando los aspectos positivos de cada uno de los
métodos de diseño analizados, los tipos de SA, así como las disímiles recomendaciones
estudiadas.
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”
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”
2.1. Introducción
Hasta ahora se ha podido analizar los aspectos más importantes a tener en cuenta a la hora de
implementar un SA que cumpla con los requerimientos impuestos por las aplicaciones y el
cliente. Luego del análisis realizado en el capítulo anterior y con el objetivo de dar cumplimiento
al objetivo planteado en este trabajo se ha propuesto un método de diseño de sistemas de
almacenamiento para Nubes Privadas con soporte para IaaS para pequeñas y medianas
empresas basado principalmente en la filosofía de diseño Top-Down, así como las pruebas para
evaluar el proyecto obtenido. La comprensión de cada una de las fases que componen el
método resulta de vital importancia para su correcta implementación en la práctica, por esta
razón en el siguiente capítulo se realizará un análisis exhaustivo de cada fase planteada.
2.2. Presentación del método de diseño
El siguiente es el método que propone el autor para el diseño de sistemas de almacenamiento

para Nubes Privadas con soporte para IaaS para pequeñas y medianas empresas. Dicho método
abarca las principales fases de la filosofía Top-Down, en la Figura 17 se muestra el diagrama
correspondiente. A su vez, este método ha sido diseñado prestando especial atención a los
diversos aspectos que se deben tener en cuenta en la confección de SA, así como en los
problemas particulares inherentes a estos sistemas que suelen surgir durante el diseño de los
mismos. De esta manera se logra un método que permite optimizar tanto los recursos como el
tiempo requerido para su culminación.
Figura 17 Método de Diseño para SA propuesto
50
Este método se compone de una fase de inicio, procesos, subprocesos y un final. Existen zonas
que son iterativas por la importancia que estas poseen y no es posible el avance hasta que se
obtenga un resultado positivo logrando así la calidad requerida.
El autor recomienda no saltarse fases ya que estas tienen un impacto directo en las posteriores
ya que la forma de diseño fue de tipo secuencial e iterativa. Cada fase del proceso será
desarrollada ampliamente en los epígrafes posteriores.
2.3. Regulaciones y/o políticas a cumplir por el sistema de almacenamiento

Las entidades pueden estas sujetas a diferentes regulaciones y restricciones tanto externas
como internas, o en algunos casos pueden estar determinadas por preferencias del cliente. Es
necesario analizarlas porque pueden marcar pauta en el diseño del SA en sí. A continuación, se
presenta una lista de los diferentes aspectos a debatir con el cliente que pueden afectar el
diseño:
- ¿Existe alguna restricción a la hora de seleccionar algún proveedor?

- ¿En cuanto a la solución en general, el cliente desea una propietaria o Software Libre y
Código Abierto (SLCA)?
- En caso de que existiese un SA implementado, desea conservarlo y optimizarlo; o
implementar una nueva solución desde cero.
- ¿En cuanto al hardware de almacenamiento desea uno dedicado o COTS?
- ¿Desea algún sistema de Almacenamiento en particular?
- ¿Planea un crecimiento de los usuarios en un rango de 5 años?
- ¿Tiene alguna restricción en cuanto a gastos a la hora de implementar el proyecto?
- En cuanto al personal que operará el SA: ¿Presentan algún tipo de conocimientos,
experiencias y/o habilidades en administración de sistemas de almacenamiento?
- ¿En cuanto a los dispositivos existentes, en caso de que alguno no cumpla con los
parámetros de calidad requerido a la hora del diseño, es necesaria su utilización?
- ¿Qué nivel de usabilidad desea que presente los softwares de administración de la
infraestructura?
- ¿Existe una herramienta de gestión y monitorización a utilizar en particular?
- ¿Qué nivel de disponibilidad desea que cumplan los servicios de las TI en la empresa?
- De los siguientes métodos para garantizar la disponibilidad de la información, seleccione
el/los que desee implementar:
a) Redundancia de información: ___2 ___3
*Se sugiere redundancia 3 ya que es la que recomiendan los principales proveedores de
soluciones.
Redundancia personalizada. Especificar el valor____
b) Salvas de MV:
51
Frecuencia Horario de inicio Backup Completo (Si Sólo archivos de

(24h) o No) configuración (Si
o NO)
__Diario
Todos los:
__Lunes __Martes
__Miércoles __Jueves
__Viernes __Sábados
__Domingos
__El día ___ de cada
mes.
Redundancia personalizada. Especificar Frecuencia ______________ y Horario de

inicio__________, Backup Completo_____ o archivos de configuración_____
2.4. Requerimientos de las aplicaciones y/o servicios a soportar por el sistema de

almacenamiento
El siguiente instrumento se hace necesario a fin de obtener los datos necesarios de las
aplicaciones que utilizarán el SA con el objetivo de evaluar los RNF que en un futuro debe
cumplir el SA y que se hace necesario que respondan a los de las aplicaciones para garantizar el
óptimo funcionamiento de las mismas. Se determina con el negocio, cuáles son las aplicaciones
existentes y las que se proyectan implementar en un plazo no mayor a los cinco años. La
caracterización debe ser llevada a cabo en función de los RNF que debe de satisfacer el SA.
Para ello se hace necesario realizar una serie de pruebas a las aplicaciones para obtener los
datos necesarios. Las siguientes pruebas son basadas en [38] como se expone en el estado del
arte, las cuales son realizadas tanto en entornos de desarrollo como en producción. Su
estructura pude ser consultada en el ANEXO F.
2.4.1 Datos Generales

La Tabla 14 recoge datos generales comunes para todas las aplicaciones. La tabla se debe llenar
con personal de la entidad que posean conocimientos de los servicios telemáticos en
producción y representantes con poder de decisión respecto a las políticas de la entidad.
1- Debe ser identificado el número de usuarios:
Presente: _______ Futuros: _______
2- Identificar los datos generales de las aplicaciones (ver tipos de aplicaciones en el Anexo H)
y los servicios a soportar.
52
Tabla 14 Identificación de aplicaciones de usuarios y de servicios
Nom Tipo Clasificación Estructura13 Criticidad Come

bre de Usu Sop Infraest Multi-tiers14 Monolítica Al Me B ntarios
de la aplic ario orte ructura Natur Despl Natur Despl ta dia aj
aplic ación aleza iegue aleza iegue a
ación
Aplicaciones Existentes
Aplicaciones Nuevas15
Aplicaciones Futuras
En caso de las multitiers:
La columna Estructura de la Tabla 14 contiene las celdas de naturaleza y despliegue, si la

aplicación puede ser desplegada en varias instancias o no, se marca la celda de naturaleza según
corresponda. Si la aplicación está desplegada en una instancia, o varias, se marca la celda de
despliegue según corresponda.
A consideración del autor se sugiere desplegarlas de forma multitiers siempre que la aplicación
lo permita porque contribuye al desempeño y elasticidad, aunque en algunos casos puede
resultar más complicada su instalación.
Para las aplicaciones existentes se realizarán pruebas en producción, mientras que para las
nuevas y futuras se consultarán las sugerencias y/o indicaciones del ecosistema16 entorno a la
aplicación en cuanto a su dimensionamiento. Se propone emplear las pruebas de desarrollo
para medir y comprobar el funcionamiento de las aplicaciones y la calidad del servicio.
3- Identificar los servicios de:
Tabla 15 Identificación de los servicios IaaS o DSaaS
IaaS: Sí: __ No: __

MV: __ Centro de Datos Virtuales (CDV): __ DSaaS:___
Si se ofrece DSaaS es necesario realizarle una encuesta al cliente para seleccionar los RF
fundamentales que debe cumplir el servicio. Estos RF influyen en la selección del software a
utilizar:
A nivel de Usuario:
1- Tipo de Almacenamiento: __SAN ___NAS ___NAS+SAN

2- Funciones de Salvas ____
13
Tributa a la tolerancia a fallos y la elasticidad, por ende, al desempeño.
14
La aplicación puede ser desplegada en varias MV.
15
Aplicaciones nuevas a agregar a corto plazo.
16
Todo aquel elemento que contribuya a la consolidación del producto, ej: libros, guías, blogs, videos tutoriales.
53
3- Acceso al servicio vía web____

4- Operaciones sobre el almacenamiento como:
__lectura ___escritura ___eliminación
A nivel de Negocio:
1- Constancia de uso de los datos____

2- Reportes de consumo con varios aspectos_____
3- Tarificación____
4- Permitir la renta de nuevos servicios o aumentar los antiguos___
5- Listado de potencialidades que puede brindar para la renta____
A nivel de Administración:
1- Monitoreo de los servicios y recursos ___

2- Rastreo del uso de los recursos periódicamente, en donde la frecuencia de emisión
pueda ser configurada___
3- Constancia de uso de datos (logs de cada usuario) ____
4- Soporte de definición de cuotas____
5- Configuración y control de las cuentas de usuario____
6- Configuración y control de los roles de seguridad____
2.4.2 Requerimiento de Utilización:

Las pruebas de utilización de forma explicada se pueden observar en el Anexo G. A continuación,
se propondrán las pruebas de forma resumida y con los cambios necesarios para adaptarlas a
las necesidades del presente trabajo.
Para entornos de producción:
Nombre de la prueba: Prueba de utilización de recursos de almacenamiento y red por MV y

servicio independiente.
Tipo de prueba: Monitoreo
Objetivo de las pruebas: Especificar el consumo de recursos de almacenamiento y red de forma

independiente para cada aplicación (MV).
Duración: Al menos un mes.
Número de iteraciones: Una.
Parámetros a ser medidos:
La Tabla 16 muestra las métricas de utilización a recogerse por aplicación independiente.
Tabla 16 Métricas de utilización de recursos de almacenamiento y red por servicio
54
Almacenamiento
Almacenamiento Capacidad (GB)
Throughput
Aplicac Servic M No Throughp
No Dimensionamiento IOPS
ión ios V do Disc Tot ut (Mbps)
utiliza
os al Adecu Su Sob Pro Ma Pro Ma
do
ado b. re m. x. m. x.
Aplicaciones Nuevas
Herramienta a utilizar: Sistema de Monitoreo Zabbix o Gestor de Nube
Descripción de las pruebas:
Instalación y configuración:
1. Instalar el nodo frontend de la herramienta de gestión (HG) en un nodo físico independiente

a los empleados para las pruebas.
2. Configurar agentes de la HG en todas las MV, así como las plantillas y disparadores
necesarios para monitorear las métricas establecidas.
Pruebas:
1. Monitorear la utilización promedio, máximo y mínimo diariamente durante al menos un mes

en el horario laboral de la entidad.
Limpieza del escenario:
No realizar limpieza del escenario
Cálculo y agregación de métricas:
1. Completar las métricas de la Tabla 16 calculando el promedio de los valores obtenidos

diariamente. Para calcular el máximo se propone utilizar el valor 90 percentil de los máximos
obtenidos por día, así se descarta cualquier comportamiento fuera de lo normal.
2. Completar las conclusiones sobre el dimensionamiento luego de obtener todas las métricas.
Prueba para entornos en desarrollo:

Es igual que la anterior, pero generando carga para obtener las métricas de la Tabla 16 Para
observar las diferencias al generar carga ver ANEXO G.
55
2.4.3 Dimensionamiento de las MV:

En la Tabla 17 se muestran las métricas para el dimensionamiento de las MV
Tabla 17 Métricas de capacidad por servicio a desplegar.
Almacenamiento
Almacenamiento Throughput
Capacidad (GB)
Aplicación Servicios MV Nodo Throughput
IOPS
Discos Total (Mbps)
Prom. Max. Prom. Max.
Aplicaciones Nuevas
TOTAL
A continuación, se indica el procedimiento para llenar la tabla correctamente:
1. Consultar con el cliente si desea mantener el dimensionamiento que tenían las MV o usar
uno propuesto por él, en este caso la tabla se completaría con los valores que el cliente
especifique. Por otra parte, el cliente puede aceptar las sugerencias y conclusiones a las que
se arribaron en la Tabla 16 respecto al dimensionamiento de las MV luego de aplicar las
pruebas de utilización y se reajustarían los valores.
2. Utilizar los datos obtenidos en la Tabla 16 para completar la tabla y dimensionar en función
de la utilización. Si se desea lograr elasticidad vertical se debe establecer como cuota
superior e inferior utilizando el máximo y promedio respectivamente. En caso de no poder
brindar elasticidad vertical se establecerá como valores de Almacenamiento y Red el valor
90 percentil de los máximos obtenido en la Tabla 16 Este dimensionamiento solo es en
función de los usuarios actuales.
3. Para dimensionar en función de los usuarios futuros de forma aproximada es necesario
aplicar la ecuación 1 a cada una de las métricas obtenidas en el paso anterior.
𝑈𝑡𝑖𝑙𝑖𝑧𝑎𝑐𝑖ó𝑛 𝑎𝑐𝑡𝑢𝑎𝑙×𝑈𝑠𝑢𝑎𝑟𝑖𝑜𝑠 𝑓𝑢𝑡𝑢𝑟𝑜𝑠
𝑈𝑡𝑖𝑙𝑖𝑧𝑎𝑐𝑖ó𝑛 𝑓𝑢𝑡𝑢𝑟𝑎 = (1)
𝑈𝑠𝑢𝑎𝑟𝑖𝑜𝑠 𝑎𝑐𝑡𝑢𝑎𝑙𝑒𝑠
4. Para dimensionar correctamente es necesario tener en cuenta las MV a desplegar para la

elasticidad horizontal, es necesario realizarle al cliente la siguiente pregunta:
¿Se van a tener en cuenta los momentos picos para desplegar nuevas MV?
Si: __ No: __
Si la respuesta es afirmativa deben adicionarse a la Tabla 16 las MV que se utilizaran para
brindar elasticidad horizontal, se utilizará el color rojo para distinguirlas.
5. Finalmente hallar el total de capacidad y throughput requerida en total por todas las
aplicaciones.
56
2.4.4 Requerimiento de Capacidades para ofrecer IaaS.
Si se va a brindar IaaS es necesario completar los datos de la Tabla 18 que recogen los recursos
asignados por cliente. Es necesario tenerlos en cuenta además del dimensionamiento por MV
para el dimensionamiento total de la infraestructura.
Tabla 18 Métricas de capacidad por servicio a brindar en la IaaS.
Almacenamiento
Almacenamiento Throughput
Capacidad (GB)
Aplicación Servicios MV Nodo Throughput
IOPS
Total (Mbps)
Total Total
2.5. Requerimientos no funcionales del sistema de almacenamiento

Uno de los pasos del método consiste en identificar los RNF del CD y en especial los del SA, con
el propósito fundamental de que el diseño posterior enfatice en los de mayores prioridades.
Para ello el autor propone el siguiente cuestionario que le servirán al diseñador conocer algunos
de los aspectos del SA que directamente dependen de las exigencias del cliente.
En el Anexo E se encuentran todos los RNF propuestos los cuales son basados en las
conclusiones y definiciones expuestas en el Epígrafe 1.5 y han sido organizados por
dimensiones, categorías, atributos, métricas y la acción propuesta por el autor para obtenerlas.
1- Seleccione de las siguientes categorías cuál desea que posea una mayor prioridad. Se
deberá asignar una numeración ascendente donde los números más bajos representan
mayor prioridad comenzando por 1. En caso de que no sea importante su prioridad dejar
en blanco.
__Escalabilidad __Compatibilidad __Desempeño __Disponibilidad __Usabilidad

__Robustez __Factibilidad __Seguridad
económica
2- En cuanto a escalar horizontalmente, ¿cuál de los siguientes aspectos representa una
problemática? Se deberá asignar una numeración ascendente donde los números más
bajos representan mayor criticidad comenzando por 1. En caso de que no sea una
problemática dejar en blanco.
__Restricciones de localización: Ej.: deben evitarse locales que limiten la expansión por su
cercanía con componentes de la edificación como elevadores, muros exteriores, etc.
__Restricciones de espacio: Es necesario verificar el espacio asignado para el SA para así poder
conocer las dimensiones del servidor a comprar y poder escalar de forma óptima.
57
__Restricciones arquitectónicas: Ej.: la altura mínima del cuarto debe ser de 2.6m desde el piso
hasta cualquier obstrucción superior como lámparas, cámaras, rociadores, etc.
__Restricciones de armarios/bastidores: Los armarios/bastidores deben estar dispuestos de tal

manera que sus partes delanteras queden frente a las partes delanteras de otra fila de
armarios/bastidores formando pasillos “fríos” y pasillos “calientes”. La distancia entre las partes
delanteras del equipamiento debe ser 1m como mínimo. Se recomiendan distancias de 1.2m.
La distancia entre partes traseras del equipamiento debe ser de 0.6m como mínimo. Se
recomiendan distancias de 1m. La altura máxima debe ser de hasta 2.4m y su profundidad de
hasta 1.1m.
__Restricciones medioambientales: Ej.: Si el cuarto no tiene un sistema de HVAC17 dedicado,
entonces debe estar localizado en un lugar que tenga acceso al sistema HVAC principal de la
edificación.
__Restricciones eléctricas: Ej.: La alimentación debe venir por parte de circuitos separados que
terminen en sus paneles eléctricos. Los tomacorrientes de 120V y 20A deben estar ubicados a
lo largo de las paredes del cuarto de cómputo con una separación de 3.65m entre ellos.
__Restricciones de consumo eléctrico: Aunque por las restricciones de la TIA, de la red y del SA
un CD tenga cierta escalabilidad horizontal, puede suceder que esa escalabilidad no sea factible
porque se sobre pase el límite de consumo de energía eléctrica que tiene planificado el CD, o
porque signifique una inversión que no es viable acometer.
__Restricciones de topologías de red: En función de la topología de red, su capacidad, las
características de los dispositivos de interconexión, los protocolos y la configuración, será el
número de servidores que podrá ser soportado.
__Restricciones de presupuesto: La escalabilidad puede estar limitada por el presupuesto
asignado para el SA por lo que es necesario conocer de cuánto se dispone para futuras compras
de equipamiento.
3- En cuanto a la flexibilidad del SA, este deberá:

__Tener soporte de pluggins __Tener facilidad de integración con herramientas de terceros
__Ser una solución SLCA modificable por el cliente.
4- En cuanto a compatibilidad:
a) ¿Qué sistema operativo se utilizará con la solución?
b) ¿Qué gestor se empleará?
5- En cuanto a capacidad:
a) ¿Qué espacio en GB deberá asignarse a utilizar por las instancias virtuales en total?
¿Qué nivel de redundancia deberá tener?
17
Siglas correspondientes al término en Inglés: Heating, Ventilation, and Air Conditioning
58
b) ¿Qué espacio en GB deberá asignarse para las salvas? ¿Qué nivel de redundancia
deberá tener?
c) ¿Qué espacio en GB deberá asignarse para ofrecer DSaaS? ¿Qué nivel de
redundancia deberá tener?
7- En cuanto al % de servicio activo, se tomará en cuenta el tiempo de mantenimiento:

__SI __NO
8- En cuanto a la usabilidad de usuario del DSaaS, clasifique las siguientes interrogantes en

Buena (B), Regular (R) o Mala (M):
__ ¿Cómo califica la independencia de dispositivo para acceder al servicio?
__ ¿Cómo califica la independencia de plataforma para acceder al servicio?
__ ¿Cómo califica la facilidad de uso del servicio?
__ ¿Cómo evalúa la posibilidad de personalización que ofrece el servicio?
__ ¿Cómo califica los esfuerzos requeridos para aprender a usar el servicio?
9- En cuanto a la usabilidad que poseen los administradores para gestionar responda las
siguientes interrogantes:
¿Cómo califican la facilidad de instalación del sistema? __Buena __Mala __Regular
¿Cómo califican la curva de aprendizaje de gestión del sistema? __Fácil __Medio __Difícil
¿Cómo califican las opciones de gestión del sistema (Web, CLI, Otra Herramienta)?
__Buena __Mala __Regular
10- En cuanto a la robustez de la solución, ¿qué aspectos se consideran prioritarios para su

selección? Se deberá asignar una numeración ascendente donde los números más bajos
representan mayor criticidad comenzando por 1.
a) En cuanto al Hardware tanto de red como de servidores del SA:
__Años en el mercado __Ranking Mundial18 __Costos __Variedad de Soporte
b) En cuanto a la solución de software del SA y salvas:
__Ranking mundial __Roadmaps __Índice de penetración __Variedad de Soporte
2.6. Caracterización del SA inicial (Opcional)

En este se lleva a cabo la caracterización del CD existente para ver cómo se cumplen los RNF a
los que se aspira. En esta tarea debe ser caracterizado el bloque funcional del SA inicial
empleando para esto las mismas pruebas planteadas en la fase de pruebas del método
propuesto en el Epígrafe 2.10. Esto permite conocer si el SA inicial es capaz de cumplir con los
18
Para ello es necesario la búsqueda en grandes consultoras internacionales como Gartner, Forrester, IDC o
RightScale
59
RNF del CD, en caso de que no sea capaz, permite conocer las limitaciones que dan origen a
estas deficiencias del SA inicial.
Si el SA inicial es capaz de cumplir con los RNF definidos en el paso anterior no habrá necesidad
de realizar ningún diseño de un nuevo SA, por lo que el método propuesto concluiría justo en
este paso de la primera fase. Esto es importante pues de no realizar esta caracterización, no se
podría llegar a esta conclusión, lo que podría traerle a la empresa gastos significativos debido al
diseño de un nuevo SA. Si por el contrario el SA inicial no es capaz de cumplir con estos
requerimientos se debe continuar con el método.
2.7. Definición del SA a desplegar en la NP

Luego de conocer los RNF que deberá cumplir el SA es la hora de la elección de la solución que
se va desplegar. Para ello el autor propone el procedimiento mostrado en la Figura 18.
Figura 18 Procedimiento para la selección del SA.
El primer paso consistirá en preguntarle al cliente si tiene como restricción el empleo de SA en

particular. Esto puede estar dado por varios motivos, alguno de ellos puede ser: 1-el personal
de la entidad posee conocimiento de un SA en particular, 2-el cliente ha heredado el SA y no
pretende modificarlo sino implementar sus nuevos servicios sobre él, 3-el cliente posee un SA
propietario el cual posee su propio software de gestión y no puede ser modificado, 4-políticas
impuesta por organismos superiores.
En caso positivo, se valorará si el sistema cumple con los RNF de las aplicaciones y del CD en
general además de las otras restricciones impuestas por el cliente (Epígrafe 2.3). Si lo anterior
es satisfactorio entonces se reutilizaría el SA inicial.
60
En caso que no exista ninguna restricción de empleo de un SA en particular o si el SA existente

no cumpliera con los RNF y las restricciones, se pasaría a la elección de una solución de SA,
preferentemente SLCA.
El segundo paso consistirá en la selección del SA en sí. Aquí se debe conocer muy bien cuando
se deberá emplear una SAN o NAS, en función de RNF, y propósito en CD, ventajas y desventajas
que traería el uso de uno u otro (Epígrafe 1.7). Además, se deberá identificar las principales
soluciones SLCA hoy en el mercado, las que destacan, para en función de esto con propiedad,
proponer (Epígrafe 1.7.4). Siempre debe abogarse por una solución, en caso de que no exista
ninguna restricción en cuanto a ello, definida por software y redes convergentes (Epígrafe 1.7.3)
con el objetivo de abaratar los costos de inversión.
Para el tercer paso, luego de haber escogido la solución se procederá con las pruebas como las
propuestas en el Epígrafe 2.10. Si son satisfactorias se procederá al siguiente paso que es el
diseño del sistema en sí. En caso negativo se deberá replantear la selección de otro SA que
responda correctamente a los RNF y restricciones impuestas.
El cuarto paso consiste en diseñar utilizando el SA elegido para lo cual debe realizarse el diseño
lógico (Epígrafe 2.8.1), el diseño físico (Epígrafe 2.8.2) y finalmente probar el SA una vez
diseñado correctamente e instalado (Epígrafe 2.10).
2.8. Diseñar tomando en cuenta las restricciones del SA definido

2.8.1 Diseño Lógico
El diseño lógico es donde comienza a moldearse el sistema en base a todo el estudio realizado
en las fases anteriores. A partir de aquí es cuando entran a jugar las experiencias y las destrezas
técnicas del equipo de diseño o del diseñador según sea el caso. Para una mayor fluidez se
propone un procedimiento el cual abarca los pasos a seguir durante esta fase del método
propuesto en este trabajo mostrado en la Figura 19.
El primer paso para comenzar con el diseño, es el diseño lógico del SA y de los subsistemas que
lo componen tal como Salvas y el almacenamiento como servicio (DSaaS). Los procedimientos
que siguen le son aplicable al SA y a sus subsistemas.
El segundo paso consiste en identificar las recomendaciones de diseño lógico propuestas por el
proveedor. En la mayoría de los casos las soluciones de software imponen topologías específicas
las cuales deben ser cumplidas ya que estas constituyen recomendaciones de los proveedores
y en la mayoría de las veces que esto es incumplido trae consigo bajo desempeño y un no
correcto funcionamiento del sistema.
61
Figura 19 Diseño Lógico
Ejemplos:
En el caso del sistema SAN Ceph, la solución impone dos redes: 1- Red cliente: la que es
encargada de la comunicación entre el SA y el acceso a la información la cuál debe ser como
mínimo de 10 Gbps; 2- Red del Clúster: la que es encargada de las operaciones propias del SA
como la replicación y el rebalanceo y recomiendan el mayor ancho de banda de red posible en
dependencia de la velocidad de escritura y lectura. Ver Anexo N para más detalles sobre su
diseño lógico.
En el caso del sistema de salvas Bácula se hace necesario 2 nodos adicionales: 1-Director que es
donde va a estar el demonio de salvas, así como el demonio web del sistema de salvas y debe
tener acceso al almacenamiento para alojar allí las salvas; 2- Server de Base de Datos necesario
para su funcionamiento y el control de las salvas. Aquí se recomienda que el almacenamiento
sea en una NAS, aunque también se puede utilizar una SAN. Ver Anexo N para más detalles
sobre su diseño lógico.
En el caso del DSaaS Pydio solo se requiere un Servidor que es donde va a estar alojado el
software de DSaaS y su interfaz web. Además, este servidor debe tener acceso al SA y se
recomienda que sea una NAS, pero también puede ser implementado en una SAN. Ver Anexo
N para más detalles sobre su diseño lógico.
El tercer paso consiste, después de saber cuál es el diseño que propone el proveedor, crear el
diseño lógico de los componentes de cada subsistema. Cada subsistema en la mayoría de los
casos posee:
62
1- Nodos de cómputo: Son los designados para el procesamiento que requiere el software
de la solución. Normalmente estos nodos poseen un mayor desempeño que los nodos
estándar. Debe leerse siempre la recomendación de HW que ofrece el proveedor para
no recaer en gastos innecesarios.
2- Nodos de control: Como su nombre lo indica son los nodos donde se realiza el control
del sistema, se establecen configuraciones y de manera general se gestiona el sistema.
Estos nodos normalmente no requieren altos rendimientos solo una conexión de red al
sistema. Normalmente los nodos de control por sus bajas prestaciones se implementan
en conjunto con los de cómputo, es decir que desde el propio nodo donde se procesa el
sistema también se realiza su control.
3- Red del Sistema: Ya que se abogará por una solución de redes convergentes es necesario
conocer algunos parámetros claves que esta debe soportar:
 Ancho de Banda: Para ello es necesario el estudio de la solución a implementar para
poder conocer el ancho de banda que requiere para su operación.
 Protocolos soportados: según un estudio realizado se muestra que VLAN es el protocolo
más empleado, permite segmentar el tráfico de la red y garantizar su aislamiento y
puede soportar 4096 VLANs. Por otro lado, los proveedores utilizan MC-LAG para evitar
los lazos y utilizar los enlaces que se bloquean con el uso de STP. En algunos casos solo
se propone el empleo de STP por si ocurre algún error o desconfiguración de MC-LAG.
Para lograr un mayor desempeño y balance de carga se apoyan en LACP. Una mayor
escalabilidad es posible con el despliegue de redes capa tres, los proveedores proponen
utilizar protocolos como OSPF, IS-IS y BGP que permiten ECMP, recomiendan OSPF para
CD pequeños y medianos, y BGP para grandes CD. Normalmente se utiliza VRRP para
garantizar redundancia en el primer salto. A consideración del autor del presente trabajo
se seleccionarán dispositivos con soporte para OpenFlow que permitan evolucionar a
una solución SDN en un futuro.
4- Gestión: Esto es necesario para mantener nuestro sistema con un correcto
funcionamiento y ser proactivo ante alguna falla. Para ello se hace necesario la elección
de una herramienta o herramientas de gestión que cubran las cinco áreas funcionales:
Fallas, Configuración, Prestaciones, Seguridad y Contabilidad (ANEXO Ñ). Como los
anteriores subsistemas presenta también su propio diseño lógico por lo que
nuevamente el autor recomienda la lectura de la documentación del proveedor.
El cuarto paso consiste en identificar los requerimientos de HW de cada subsistema mencionado

anteriormente. Para ello el autor propone los que son recomendados por los proveedores.
El quinto paso consiste en identificar cada sistema en particular el espacio que requiere para su
funcionamiento y posteriormente (sexto paso) obtener la capacidad de almacenamiento total
requerida, así como los requerimientos de Hardware total (incluye red). Para ello el autor
propone la siguiente tabla:
63
Tabla 19 Capacidades por subsistema
Cómputo
Red Requerida Mínimo
Capacidad en
Factor de Necesario
Sistema Nodo GB sin
Redundancia Ancho de
redundancia Número de
banda CPU RAM
interfaces
requerido
Salvas
DSaaS
SA
Para el cálculo de la capacidad final que deberá soportar el SA el autor propone las siguientes
fórmulas:
𝐶𝑎𝑝𝑎𝑐𝑖𝑑𝑎𝑑 𝑇𝑜𝑡𝑎𝑙 𝑑𝑒𝑙 𝑆𝐴 𝑅𝑒𝑞𝑢𝑒𝑟𝑖𝑑𝑎 = 𝐶𝑎𝑝𝑎𝑐𝑖𝑑𝑎𝑑 𝑇𝑜𝑡𝑎𝑙 𝑝𝑎𝑟𝑎 𝑆𝑎𝑙𝑣𝑎𝑠 ∗

𝐹𝑎𝑐𝑡𝑜𝑟 𝑑𝑒 𝑟𝑒𝑑𝑢𝑑𝑎𝑛𝑐𝑖𝑎 + 𝐶𝑎𝑝𝑎𝑐𝑖𝑑𝑎𝑑 𝑇𝑜𝑡𝑎𝑙 𝐷𝑆𝑎𝑎𝑆 ∗ 𝐹𝑎𝑐𝑡𝑜𝑟 𝑑𝑒 𝑟𝑒𝑑𝑢𝑛𝑑𝑎𝑐𝑖𝑎 (2)
𝐶𝑎𝑝𝑎𝑐𝑖𝑑𝑎𝑑 𝐷𝑖𝑠𝑝𝑜𝑛𝑖𝑏𝑙𝑒 = 𝐶𝑎𝑝𝑎𝑐𝑖𝑑𝑎𝑑 𝑇𝑜𝑡𝑎𝑙 𝑑𝑒𝑙 𝑆𝐴 −

𝐶𝑎𝑝𝑎𝑐𝑖𝑑𝑎𝑑 𝑇𝑜𝑡𝑎𝑙 𝑑𝑒𝑙 𝑆𝐴 𝑅𝑒𝑞𝑢𝑒𝑟𝑖𝑑𝑎 (3)
El séptimo paso consiste en realizar las pruebas para validar si lo implementado realmente
responde a las expectativas y a los RNF. Para ello el autor propone el sistema de pruebas del
Epígrafe 2.10.
En caso de ser satisfactorias se documenta el proceso y terminaría esta fase. En caso negativo
el proceso comienza nuevamente por el paso dos.
2.8.2 Diseño Físico
En esta fase se comienzan a añadir por primera vez los componentes físicos que formarán parte
del SA. Es de gran importancia realizar una buena selección, pues estos son los que determinan
en gran medida el futuro rendimiento y estabilidad del sistema. Aunque se tenga un buen
diseño lógico que cubra con todos los requerimientos planteados, si este no está acompañado
de unos componentes que lo respalden la solución planteada carecerá de madurez y eficacia.
Al igual que en las demás fases estudiadas hasta ahora, se propone un procedimiento para
simplificar esta fase de diseño del sistema mostrado en la Figura 20.
64
Figura 20 Diseño Físico
El primer paso del diseño físico consistirá en valorar las condiciones físicas del local será
instalado el SA. Esto es de vital importancia para el diseño ya que este factor imprime varias
restricciones al diseño como son:
 Cantidad de nodos de almacenamiento que puede soportar el sistema

 Cantidad de dispositivos de interconexión a soportar por el SA.
 Complejidad del sistema de enfriamiento.
 Complejidad del sistema de alimentación eléctrica.
Para mitigar estos efectos es necesario analizar varios elementos del local que influyen directa
e indirectamente sobre el SA y los demás sistemas del CD en general. Del análisis de estos
elementos depende en gran medida la posible aplicabilidad del proyecto de almacenamiento e
incluso puede encarecer más los costos debido a la compra o alquiler de algún local que reúna
las condiciones adecuadas para la implementación del SA. Los elementos críticos a tener en
cuenta son:
 Dimensiones, particularmente las disponibles para el SA (rack o torre según se necesite)

 Capacidad de climatización y tratamiento de la humedad
 Capacidad eléctrica
 Seguridad del local
 Mecanismos de protección contra desastres
65
El segundo paso lo constituye la interrogante siguiente ¿existe una infraestructura de

almacenamiento en concepto de hardware desplegada?
Esto tiene como objetivo fundamental reducir los costos del SA en la medida de lo posible,
mediante la utilización de equipos de la empresa para el SA, esto evitaría la compra de
equipamiento extra para el sistema. Muchas empresas poseen en sus CD equipamientos que
no se encuentran realizando labores importantes para la empresa por lo que hay veces que se
puede prescindir de ellos y sus funciones pueden pasar a otros equipos, esto depende mucho
de las condiciones particulares que existan en cada CD por lo que el nivel de cumplimiento de
este paso no siempre será el mismo en las empresas y en muchas ocasiones puede resultar
totalmente contraproducente su realización.
En caso de ser afirmativa conduce a otra interrogante ¿cumple con el diseño lógico
recomendado por el proveedor? Para responder a esta interrogante se debe haber realizado
previamente el diseño lógico (Epígrafe 2.8.1). En caso de que sea negativo proseguimos con el
paso tres.
El tercer paso lo constituye la elección en sí del Nuevo Hardware, el cual, evidentemente debe
cumplir con los RNF y el diseño lógico antes planteado. Para elegir el nuevo Hardware el autor
propone las siguientes recomendaciones:
1- En primer lugar, realizar un estudio para conocer cuáles son los principales proveedores
de Hardware, tanto para almacenamiento como para red a nivel mundial. Para ello el
autor recomienda la búsqueda de estos en consultoras de prestigio internacional como
Forrester19, Gartner20 ,IDC21 o RightScale22. Un estudio de estos proveedores se realizó
en el Epígrafe 1.3.
2- Luego de tener identificado a los principales proveedores de Hardware es momento de
buscar las ofertas/soluciones que estos proponen, por su puesto, eligiendo aquellas que
cumplan con el diseño establecido
3- Luego de tener identificada las soluciones nos enfocamos a ver la renovación de los
productos y los roadmaps de las soluciones de software. El autor propone elegir aquella
a la cual le den un mayor soporte, así como la que muestre mayor acogida a nivel
mundial.
19
Forrester Research es una empresa independiente de investigación de mercados que brinda asesoramiento
sobre el impacto existente y potencial de la tecnología a sus clientes y al público en general.
20
Gartner Inc. es una empresa consultora y de investigación de las tecnologías de la información con sede en
Stamford, Connecticut, Estados Unidos.
21
International Data Corporation (IDC) es el principal proveedor mundial de inteligencia de mercado, servicios
de asesoramiento y eventos para el mercado de tecnología de la información, telecomunicaciones y tecnología
de consumo.
22
RightScale permite a las empresas líderes acelerar la entrega de aplicaciones basadas en la nube que atraen a
los clientes y generan ingresos de primera línea mientras optimizan el uso de la nube para reducir el riesgo y los
costos.
66
4- Después de tener definida la solución es posible tener uno o más proveedores que
cumplan con los requisitos anteriores. Para ello se realiza un análisis de la relación
Costo/Prestigio donde la decisión final queda en manos del cliente.
Por último, documentar todo el proceso y las características de la solución escogida.
En caso en que la respuesta del segundo paso sea positiva nos dirigimos al paso tres alternativo
donde comprobamos si el Hardware heredado cumple con los requerimientos y la capacidad
total es la requerida. En caso positivo se procede a la documentación final. En caso negativo, no
necesariamente puede ser problema de Hardware, sino que es posible que sea necesario con
ese mismo HW agregar un componente extra. Si no es necesario, se procede con el paso tres,
en caso afirmativo, se procedería a analizar los datos que ofrece el proveedor acerca de la
obsolescencia. Si se comprueba que es obsoleto entonces no vale la pena adquirir un nuevo
equipamiento para este tipo de caso ya que podría en un futuro provocar pérdidas innecesarias
a la hora de buscar piezas de repuesto que es posible que ya no estén a la venta por el proveedor
oficial; y entonces se pasaría nuevamente al paso tres. En caso que no sea obsoleto entonces si
podemos elegir los componentes necesarios.
Estos componentes extras pueden ser necesarios para el funcionamiento del SA como discos
duros (Epígrafe 1.8) y nuevas tarjetas de red. En este paso resulta importante tener en cuenta
nuevamente el fabricante de cada uno de los componentes que se van a emplear en el sistema
pues cada uno de ellos goza de diferentes grados de consolidación a nivel internacional y poseen
diferentes políticas de garantía y atención técnica, esto puede afectar indirectamente el
rendimiento a largo plazo del sistema.
Otro aspecto a tener en cuenta durante esta selección es el presupuesto aprobado para el SA,
se debe tener cuidado de no superar los límites establecidos debido a la búsqueda de los
mejores componentes individuamente, por lo que en ocasiones habrá que tomar decisiones
para adquirir los componentes con la mejor relación calidad/precio posible en función del
presupuesto disponible.
Finalmente documentar todo el proceso.
2.10. Pruebas para caracterizar y evaluar el sistema de almacenamiento
El siguiente modelo de pruebas se compuso basado en los aspectos propuestos en el Epígrafe
1.9 con el objetivo de validar el SA a utilizar y los RNF propuestos por el autor en el ANEXO E. En
este caso se emplearon herramientas de software libre y código abierto para la obtención de
los resultados dada la naturaleza del SA a emplear las cuales se describen en la Tabla 20. Es
preciso destacar que lo importante de este modelo es la estructura que presenta, la cual es
aplicable a cualquier SA, obviamente, modificando algunos parámetros como la configuración
de la herramienta. Los restantes RNF no presentan un modelo de pruebas por lo que deben
evaluarse según las métricas definidas en el ANEXO E.
67
Tabla 20 Herramientas para realizar las pruebas al SA.
Herramienta Tipo Descripción

Es una herramienta de benchmarking creada específicamente para
analizar el rendimiento de los discos. Permite medir las principales
métricas que definen la calidad de los mismos. Su característica más
Fio SLCA
distintiva es su flexibilidad, ya que permite diversas configuraciones
para adaptar y condicionar las pruebas. Presenta varios motores para
generar peticiones a los discos.
Iperf es una herramienta que se utiliza para hacer pruebas en los
enlaces entre dos nodos. El funcionamiento habitual es crear flujos de
datos TCP y UDP y medir el rendimiento de la red. Iperf permite al
usuario ajustar varios parámetros que pueden ser usados para hacer
Iperf SLCA
pruebas en una red, o para optimizar y ajustar la red. Iperf puede
funcionar como cliente o como servidor y puede medir el rendimiento
entre los dos extremos de la comunicación, unidireccional o
bidireccionalmente.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
PRUEBA #1
Nombre de la Prueba: Pruebas de Throughput del SA.
Tipo de prueba: Microbenchmark.
Duración: Cuatro horas.
Número de iteraciones: Cuatro.
Objetivo: Medir el throughput de los discos y de la red del SA.
Parámetros a ser medidos
1. Throughput de lectura y escritura de los discos duros.

2. Operaciones por segundo de los discos duros.
3. Throughput de lectura y escritura del clúster del SA.
4. Operaciones por segundo del clúster del SA.
5. Throughput de la red.
Recursos a emplear:
Para realizar las pruebas de throughput e IOPS en los discos se empleará la herramienta Fio
mientras que para realizar las pruebas de throughput en la red del SA se empleará la
herramienta Iperf.
Descripción de la prueba:
1. Instalar la herramienta Fio empleando el comando: aptitude install fio.
68
2. Conectarse al SA empleando ssh y dirigirse hacia el HDD a probar empleando el

comando cd /dev/sdx.
3. Crear en el disco una carpeta de nombre benchmark-fio empleando el comando mkdir
benchmark-fio.
Pruebas:
1. Para determinar el throughput y los IOPS de las operaciones correspondientes a la

escritura y lectura aleatoria ejecutar el comando “fio --name=randwrite --
ioengine=libaio --iodepth=1 --rw=randwrite --bs=(tamaño bloque) --direct=0 --
size=256M --numjobs=8 --runtime=240 --group_reporting” para la lectura aleatoria y el
comando “fio --name=randread --ioengine=libaio --iodepth=16 --rw=randread --
bs=(tamaño bloque) --direct=0 --size=256M --numjobs=8 --runtime=240 --
group_reporting” para la lectura aleatoria.
2. Para determinar el throughput y los IOPS de las operaciones correspondientes a la
escritura y lectura secuencial ejecutar el comando “fio --name=write --ioengine=libaio -
-iodepth=1 --rw=write --bs=(tamaño bloque) --direct=0 --size=256M --numjobs=8 --
runtime=240 --group_reporting” y para la lectura secuencial el comando “fio --
name=read --ioengine=libaio --iodepth=16 --rw=read --bs=(tamaño bloque) --direct=0 -
-size=256M --numjobs=8 --runtime=240 --group_reporting” para la lectura aleatoria.
Los tamaños de bloques a emplear serán 4KB, 64KB, 256KB y 1024KB debido a que se desea
comprobar el rendimiento de los discos con diferentes tamaños de bloques puesto que el SA
será expuesto a ficheros de tamaño variable.
3. Para determinar el throughput en la red del SA ejecutar primeramente en un nodo del

clúster el comando “iperf -s”, posteriormente ejecutar en los demás nodos del clúster el
comando “iperf –c (IP del nodo donde se ejecutó iperf -s) –f M –t 300”. Los resultados
se recopilan en forma de salida por pantalla. Este procedimiento debe reiterarse
ejecutando el comando “iperf –s” en otro nodo del clúster y ejecutando el otro comando
en los nodos restantes.
4. Ir a la página oficial de la herramienta FIO para realizar las pruebas descritas
anteriormente pero ahora al clúster del SA. Se hace necesario ir a la documentación
oficial ya que la herramienta tiene formas de configuración específica para testear SA
pero que difieren unas de otra.
1. Desinstalar las herramientas definidas para la realización de las pruebas.

2. Eliminar los archivos generados y la carpeta benchmark-fio
Análisis y procesamiento de los resultados:
1. Calcular el promedio de las muestras de las distintas iteraciones.
69
2. Generar los gráficos empleando los datos de throughput e IOPS de las diferentes
operaciones analizadas.
3. Generar las tablas correspondientes al Throughput de la red tanto pública como del
clúster de almacenamiento respectivamente.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
PRUEBA #2
Nombre de la Prueba: Pruebas de tiempo de respuesta del SA.
Tipo de prueba: Microbenchmark.
Duración: Cuatro horas.
Número de iteraciones: Cuatro.
Objetivo: Obtener los tiempos de respuesta para las distintas operaciones realizadas sobre los
discos y el SA en general.
Las métricas a medir son los tiempos de respuesta de los discos y del SA a distintos tamaños
de bloques.
Recursos a emplear:
La herramienta utilizada en la realización de estas pruebas fue FIO.
1. Instalar Fio mediante el comando “aptitude install fio”
2. Conectarse al SA utilizando ssh, dirigiéndose hacia el HDD a probar.
3. Crear en el disco una carpeta de nombre benchmark-fio empleando el comando “mkdir

benchmark-fio”.
Pruebas:
1. Emplear los comandos de la herramienta Fio descritos en la PRUEBA #1 para determinar

las latencias en las operaciones de lectura y escritura tanto secuencial como aleatoria en
los discos que componen el SA.
2. Configurar la herramienta Fio para efectuar las mismas pruebas al SA en forma de clúster.
Ir al sitio oficial de FIO para conocer las instrucciones a efectuar.
1. Desinstalar la herramienta Fio
70
2. Borrar la carpeta creada en los discos probados
1. Calcular el promedio de las muestras de las distintas iteraciones.
2. Generar los gráficos empleando los datos de latencia de las diferentes operaciones
realizadas en los HDD y en el clúster del SA.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
PRUEBA #3
Nombre de la Prueba: Prueba de escalabilidad
Tipo de prueba: Monitoreo
Duración: dos horas
Número de iteraciones: Tres.
Objetivos: Comprobar la habilidad que posee el SA para aumentar y disminuir su capacidad de

almacenamiento mediante el acople y desacople de nodos.
Parámetros a ser medidos:
1. Tolerancia a fallos
2. Recuperación ante fallos
3. Confiabilidad
4. Escalabilidad Horizontal
Recursos a emplear:
Herramienta de monitoreo del propio SA.
1. Instalar el SO
2. Configurar las interfaces de redes
3. Instalar los paquetes del SA.
Pruebas:
1. Conectar inicialmente dos nodos y observar como el SA reconoce la capacidad de

almacenamiento que proveen los discos de ambos nodos.
2. Realizar el acople del tercer y cuarto nodo realizando las mismas operaciones para
monitorizar el acople de estos al SA.
3. Remover un nodo del sistema y monitorizar el estado.
71
En esta prueba no se hace necesario la limpieza del escenario puesto que no se empleó
ninguna herramienta externa al funcionamiento del SA.
Verificar si el sistema pudo escalar de forma horizontal correctamente sin que hubiera pérdida
de información.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
PRUEBA #4
Nombre de la Prueba: Prueba de estrés al sistema de almacenamiento
Tipo de prueba: Desempeño
Duración: ocho horas.
1. Uso de la Red del SA

2. Recursos de cómputo (Micro, CPU, RAM)
3. Uso de los discos.
Recursos a emplear:
Para esta prueba se empleará la herramienta FIO y una herramienta de monitoreo.
1. Configurar la herramienta FIO para generar escrituras y lecturas aleatorias con varios
tamaños de bloques en cada nodo del SA.
2. Luego de configurar la herramienta FIO ejecutarla de forma simultánea en todos los
nodos que componen el SA lo cual simulará las distintas peticiones de E/L de los clientes
al SA en un ambiente de alta demanda.
Desinstalar las herramientas definidas para la realización de las pruebas.
Análisis y procesamiento de los resultados
Acceder a la herramienta de monitoreo y recolectar los valores correspondientes al:
 Uso del CPU

 Uso de la RAM
 Uso de la Red Cliente
72
 Uso de la Red del Clúster

 Carga del clúster.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
PRUEBA #5
Nombre de la Prueba: Prueba de disponibilidad del SA.
Tipo de prueba: Disponibilidad
Duración: un mes
Objetivo: Medir el grado de disponibilidad que presenta el SA.
1. Porcentaje de servicio activo

2. Tolerancia a fallos
3. Recuperación ante fallos
4. Confiabilidad
Recursos a emplear:
Herramienta de monitoreo.
Pruebas:
1. Monitorear el comportamiento del SA durante un mes.

2. En caso de alguna falla ver su tiempo de recuperación.
No es necesaria la limpieza del escenario en esta prueba.
Analizar el comportamiento del SA y calcular su porciento de servicio activo.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
PRUEBA #6
Nombre de la Prueba: Prueba de utilización del SA.
Tipo de prueba: Desempeño
Duración: Permanente
Número de iteraciones: --
73
Objetivo: Medir la utilización de los recursos de almacenamiento, red y cómputo del SA en un

entorno de producción.
1. Utilización de la Red de Acceso al SA.

2. Utilización de la Red del clúster del SA.
3. Utilización de los discos independiente.
4. Utilización del clúster de almacenamiento.
5. Utilización de los recursos de cómputo (CPU, RAM)
Recursos a emplear:
Herramienta de monitoreo.
Pruebas:
Monitorear el uso del SA en producción en el horario de mayor demanda por parte de los
usuarios en el lugar donde se encuentra implementado el SA.
No es necesaria la limpieza del escenario en esta prueba.
Analizar el uso de los recursos mencionados y llegar a conclusiones.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
PRUEBA #7
Nombre de la Prueba: Prueba de eficiencia del SA.
Tipo de prueba: Eficiencia
Duración: Ocho horas
Número de iteraciones: Tres
Objetivo: Obtener métricas de eficiencia energética y de capacidad del SA
1. Potencia total consumida por el SA.

2. Capacidad utilizada/Capacidad total en %
3. GB/watt
4. IOPS/watt
5. Mbps/watt
74
Recursos a emplear:
1. Herramienta de monitoreo.
2. SPECpower_ssj2008.
3. Herramienta stress y scripts de prueba.
Para las pruebas de Eficiencia se requieren entradas de energía independientes para el SA y

equipos de medición especializados, para lo que se recomienda seguir las especificaciones de
SPECpower_jss2008 en su selección. Para el caso de clientes que no cuenten con estos recursos
se necesitan metros de potencia y herramientas para generar carga a los procesadores de forma
controlada, para lo cual se recomienda la herramienta stress disponible en los repositorios de
la mayoría de las distribuciones Linux, o scripts de trabajo que generen cargas intensivas.
1. Instalar stress directamente sobre todos los nodos del SA.

2. Correr las pruebas definidas en los scripts de la herramienta.
Pruebas:
1. Medir el consumo de potencia con todos los nodos del SA encendidos y ninguna
tarea ejecutándose durante 10 minutos.
2. Ejecutar stress directamente sobre todos los nodos del CD y medir el consumo
de energía del CD durante 10 minutos.
3. Durante cada fase se monitoriza la:
 Potencia total consumida por el SA.
 Capacidad utilizada/Capacidad total en %
 GB/watt
 IOPS/watt
 Mbps/watt
1. Eliminar las herramientas instaladas
1. Calcular media, desviación estándar y umbral del 95 % percentil para cada valor de las
métricas.
2. Calcular curva de utilización de recursos y consumo de energía para el SA.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
75
2.11. Identificación del sistema de salvas

Luego de haber implementado el SA se hace necesario un sistema de salvas por las razones
antes expuestas (Epígrafe 1.11). Para ello el autor propone el procedimiento que se observa
en la Figura 21.
Figura 21 Procedimiento para identificar el sistema de salvas
El primer paso para comenzar con el procedimiento será la siguiente interrogante que deberá
realizarse al cliente ¿existe como restricción el empleo de una solución en particular?, la cual
en caso afirmativo conlleva a una segunda interrogante que deberá realizarse el diseñador
¿cumple con los RNF y las restricciones? Y en caso de ser afirmativa se procederá a su
implementación en un sistema tipo NAS ya que es el recomendado para estos fines.
En caso opuesto que no exista una restricción de uso de una solución en particular o que la
solución que se propuso no cumpliera con los RNF entonces se continuará con la siguiente
interrogante ¿el gestor de Nube posee su propio sistema de salvas? Esto es muy importante ya
que en varios casos el gestor posee su propio sistema de salvas integrado con funcionalidades
que cumplen con los requerimientos expuestos y no se hace necesaria la aplicación de una
nueva solución.
En caso de que el gestor incluya un sistema de salvas se realiza la misma interrogante que al
inicio ¿cumple con las restricciones y los RNF? En caso afirmativo se procede a su
implementación. En caso negativo nos vamos a elegir una solución en el mercado.
Para la búsqueda de una solución en el mercado es muy importante, en primer lugar, que sea
SLCA, en segundo lugar, que cumpla con los RNF y restricciones, en tercer lugar, que tenga
76
usabilidad y en cuarto lugar que tenga soporte. Una comparativa entre las principales soluciones
de salvas más utilizadas se encuentra en el Epígrafe 1.11.
Después de elegida la solución se procede a las pruebas preliminares antes de su

implementación en entornos de producción. Aquí es donde se le realizan pruebas de concepto
al software en los principales RF que debe cumplir. Si las pruebas no son satisfactorias será
necesaria la elección de otra solución que se acople mejor a las necesidades de la empresa. En
caso positivo se procede al diseño del sistema para lo que se recomienda seguir los pasos
propuestos en el Epígrafe 2.8.1 y 2.8.2.
2.12. Conclusiones
El método propuesto en este capítulo cumple con el diseño top-down y es aplicable a todas las
pequeñas y medianas empresas bajo el paradigma de la Computación en la Nube. Este método
toma en cuenta desde un inicio las necesidades de la institución lo que garantiza un diseño
adaptado a las condiciones y requerimientos reales del negocio. Ofrece una serie de
herramientas y pasos de diseño para la correcta implementación del mismo, así como para
disminuir el tiempo de despliegue.
77
Datos”

Datos”
3.1. Introducción
El método planteado en el capítulo anterior debe pasar por un proceso de validación para
demostrar la eficacia real que posee cuando es llevado a la práctica. Mediante este proceso se
comprueba si es capaz de crearse un SA acorde a las necesidades de las instituciones, su
capacidad de aportar claridad en el proceso de diseño, y sobre todo si su estructura permite
evitar problemas comunes que se presentan en el diseño de estos sistemas, ahorrando tiempo
de ejecución. Para llevar a cabo esta tarea se seleccionó a la Universidad Tecnológica de La
Habana (CUJAE).
3.2. Regulaciones y/o política a cumplir por el SA

Antes de conocer las regulaciones y/o políticas a cumplir por el SA es necesario conocer la
misión y la visión del centro donde se va a implementar.
En este caso se implementó en la Universidad Tecnológica de La Habana (CUJAE) cuya misión y

visión son las siguientes:
Misión:
La CUJAE es una Universidad comprometida con su Patria y sus deberes internacionalistas en la

formación integral y continua de profesionales, la universalización de la enseñanza, la actividad
científico técnica y la extensión universitaria y se propone contribuir de forma significativa a la
Batalla de Ideas y al desarrollo sostenible de la sociedad cubana revolucionaria, con liderazgo
nacional y prestigio internacional en el campo de las ciencias técnicas.
Visión:
 Un baluarte de la Revolución expresado por su participación activa en el desarrollo de

nuestra sociedad socialista y de otros pueblos, con graduados comprometidos e
integrales que alcanzan niveles cualitativamente superiores de formación en todos los
tipos de cursos.
 Un centro de excelencia en el desarrollo de los procesos de gestión de la universidad,
por su integración con todos los organismos relacionados con la nueva universidad
cubana a todos los niveles, que fortalece su papel rector en las ciencias técnicas.
 Un modelo de universidad tecnológica de excelencia en el ámbito latinoamericano, con
reconocimiento internacional por sus programas de formación acreditados y por el
impacto de sus resultados científico técnicos, comprometido con la integración
latinoamericana.
Actualmente, el instituto se encuentra inmerso en una estrategia de informatización, cuyo

propósito es impulsar el uso de las TIC en la formación integral de sus estudiantes y en todos
78
Datos”
los procesos sustantivos del centro. La VRIC acorde a dicha estrategia ha trazado las siguientes
metas:
 Mantener los niveles de los servicios ofrecidos por la Red-CUJAE haciendo un uso más
eficiente de los recursos disponibles.
 Aumentar la cantidad y calidad de servicios ofrecidos por la Red-CUJAE a partir de la
disponibilidad de hardware.
 Aumentar la productividad del personal que gestiona el CPD mediante la explotación de
las facilidades ofrecidas por tecnologías más recientes.
 Disponer de la infraestructura necesaria para introducir nuevos modelos de servicios en
la universidad.
 Beneficiar a facultades y centros del instituto con los modelos de servicios propios de
las tecnologías actuales, reduciendo las necesidades de adquisición de hardware.
En toda esta estrategia de informatización el almacenamiento constituye uno de los elementos

claves, por lo que es necesario diseñar un sistema de almacenamiento que garantice
redundancia en la información y alta tolerancia a fallas, y además tiene que cumplir con las
características, y requerimientos técnicos y funcionales para el despliegue de una Nube.
Dado que la CUJAE es un centro de altos estudios se hace necesario el correcto funcionamiento
de los servicios que esta ofrece de la vida académica asegurando la calidad del proceso
educativo. Para ello es vital que los servicios ofrecidos por ella tengan un correcto
funcionamiento y además, en caso de algún fallo tenga una rápida recuperación por lo que
definitivamente es necesario un SA.
Antes de su implementación es necesario conocer las regulaciones y/o política a cumplir por el
SA. Para ello se realizó la encuesta propuesta en el Epígrafe 2.3 a los administradores de red de
la Universidad.
- ¿Existe alguna restricción a la hora de seleccionar algún proveedor?

R/ Si, debe ser uno que me ofrezca soluciones COTS.
- ¿En cuanto a la solución en general, el cliente desea una propietaria o Software Libre y
Código Abierto (SLCA)?
R/Preferiblemente SLCA
- En caso de que existiese un SA implementado, desea conservarlo y optimizarlo; o
implementar una nueva solución desde cero.
R/No existe una solución implementada así que, desde cero.
- ¿En cuanto al hardware de almacenamiento desea uno dedicado o COTS?
R/Preferiblemente COTS para abaratar los costos.
- ¿Desea algún sistema de Almacenamiento en particular?
R/No
- ¿Planea un crecimiento de los usuarios en un rango de 5 años?
79
Datos”
R/ Por las características de la universidad no se espera un crecimiento de los usuarios, de

hecho, siempre oscila en la misma cantidad.
- ¿Tiene alguna restricción en cuanto a gastos a la hora de implementar el proyecto?
R/ Si, no poseemos un fondo dedicado a ello.
- En cuanto al personal que operará el SA: ¿Presentan algún tipo de conocimientos,
experiencias y/o habilidades en administración de sistemas de almacenamiento?
R/El personal que administra los servicios de la institución normalmente está poco tiempo
ocupando esa plaza por lo que los futuros administradores puede que no tengan habilidades
con respecto a los SA
- ¿En cuanto a los dispositivos existentes, en caso de que alguno no cumpla con los
parámetros de calidad requerido a la hora del diseño, es necesaria su utilización?
R/ Si, dada la falta de presupuesto para adquirir mejores.
- ¿Qué nivel de usabilidad desea que presente los softwares de administración de la
infraestructura?
R/La más alta posible
- ¿Existe una herramienta de gestión y monitorización a utilizar en particular?
R/ Si, ya que no disponemos de hardware suficiente deseamos utilizar Zabbix.
- ¿Qué nivel de disponibilidad desea que cumplan los servicios de las TI en la empresa?
R/La mayor posible.
- De los siguientes métodos para garantizar la disponibilidad de la información, seleccione
el/los que desee implementar:
a) Redundancia de información: ___2 _X_3
*Se sugiere redundancia 3 ya que es la que recomiendan los principales proveedores de
soluciones.
Redundancia personalizada. Especificar el valor____
b) Salvas de MV:
Frecuencia Horario de inicio (24h) Backup Completo (Si Sólo archivos de

o No) configuración (Si
o NO)
__Diario
Todos los: 02:00 X
__Lunes __Martes
__Miércoles __Jueves
__Viernes __Sábados
_X_Domingos
__El día ___ de cada
mes.
Redundancia personalizada. Especificar Frecuencia ______________ y Horario de
inicio__________, Backup Completo_____ o archivos de configuración_____
80
Datos”
3.3. Requerimientos de las aplicaciones

Luego de conocer las restricciones que deberá cumplir el SA, es necesario conocer las
aplicaciones que sobre este se desplegarán. Para ello se aplicará el método propuesto en el
Epígrafe 2.4.
1- En cuanto a la identificación del número de usuario se estimó que aproximadamente

utilizarán el servicio una población total de 8000 usuarios que incluyen a trabajadores,
estudiantes y profesores. Lógicamente todos los usuarios no están simultáneamente
conectados así que se estima que estén en línea aproximadamente 1000 usuarios.
3.3.1 Datos Generales

Para la caracterización de las aplicaciones se escogió un servicio crítico para la universidad: el
servicio de navegación de internet. Este servicio está formado por los SquidNat que son los que
van de cara a internet y los Squid que son los que proveen el control de acceso a los usuarios
al SquidNat. Por razones de tiempo se escogió uno de los squid que en estos momentos brinda
servicio a los usuarios. Los datos generales de este servicio se observan en la Tabla 21.
Tabla 21 Datos Generales servicio Navegación de Internet
Clasificación Estructura23 Criticidad Comen

Nombr Usu Sop Infraestr Multi-tiers24 Monolítica Al Me Ba tarios
e de la ario orte uctura Natur Despli Natur Despli ta dia ja
aplicac aleza egue aleza egue
ión
Servici X X X X
o de
Naveg
ación
de
Intern
et
A continuación, se procedió a identificar los servicios de:
Tabla 22 Identificación de los servicios IaaS o DSaaS
IaaS: Sí: _X_ No: __

MV: _X_ Centro de Datos Virtuales (CDV): __ DSaaS:___
En estos momentos no se está ofreciendo DSaaS, pero se planea en un futuro su utilización.

Para ello utilizar la encuesta del Epígrafe 2.4.1.
23
Tributa a la tolerancia a fallos y la elasticidad, por ende, al desempeño.
24
La aplicación puede ser desplegada en varias MV.
81
Datos”
3.3.2 Requerimiento de Utilización:
Entornos de Producción
La Tabla 23 muestra las métricas de utilización correspondientes a uno de los squids encargados
de ofrecer el servicio de internet a los usuarios utilizando la prueba definida en el Epígrafe 2.4.2
Tabla 23 Métricas de utilización de recursos de almacenamiento y red por servicio
Almacenamiento Capacidad (GB) Almacenamiento Throughput

Dimensionamie
No IOPS Throughput (Kbps)
Aplica nto
MV Nodo Dis To utili
ción S So Pr M
cos tal zad Adec
u br om ax Prom. Max.
o uado
b. e . .
L E L E
Naveg
ación 25 5
Squi yoda.cuja 10 10. 72
por 1 7.4 x 1.5 34 3. 4
d03 e.edu.cu .7 25 0
intern 7 4
et
Comentario: Podemos observar que el servicio squid de cara a los usuarios es una aplicación
que utiliza pocos recursos tanto de almacenamiento como de Red.
Prueba para entornos en desarrollo:

Para entornos de desarrollo se aplicaron las pruebas de carga definidas en el ANEXO G.
Almacenamiento
Almacenamiento Capacidad (GB)
Throughput
Aplica Dimensionamie Throughput
MV Nodo No IOPS
ción Dis To nto (Kbps)
utiliz
cos tal Adec Su So Pro M
ado Prom. Max.
uado b. bre m. ax.
L E L E
Carga ascendente
Naveg
ación
Squi yoda.cuja 10 0.4 1, 2.6 2
por 1 7.4 x 3
d03 e.edu.cu .7 3 10 1 0
intern
et
Carga descendente
Naveg
ación 1
Squi yoda.cuja 10 0.7 0, 10.
por 1 7.4 x 3 3
d03 e.edu.cu .7 6 88 83
intern 6
et
Carga por Picos
82
Datos”
Naveg
ación
Squi yoda.cuja 10 0.4 3. 1, 3
por 1 7.4 x 2.1
d03 e.edu.cu .7 37 2 55 2
intern
et
Sobrecarga
Naveg
ación
Squi yoda.cuja 10 2, 4
por 1 7.4 x 0.8 4 4.4
d03 e.edu.cu .7 10 0
intern
et
Comentario: Podemos observar que el comportamiento generando cargas es muy similar a un
día típico lo que confirma que, a pesar de exponer el servicio bajo ciertas condiciones
anormales, aun así, no tiene influencia alguna sobre el almacenamiento.
3.3.3 Dimensionamiento de las MV:

En la Tabla 24 se muestran las métricas para el dimensionamiento del servicio squid. Para su
completamiento se aplicó el procedimiento definido en el Epígrafe 2.4.3
Tabla 24 Métricas de capacidad por servicio a desplegar.
Almacenamie
nto Capacidad Almacenamiento Throughput
Aplicació (GB)
MV Nodo
n IOPS Throughput (Kbps)
Discos Total Pro Ma
Prom. Max.
m. x.
L E L E
Navegaci
Squid yoda.cujae.ed 10.2 253. 20.4 45
ón por 1 5 1.5 4
03 u.cu 5 7 5 0
internet
10.2 253. 20.4 45
TOTAL 1 5 1.5 4
5 7 5 0
Comentario: Podemos observar luego de dimensionar correctamente el servicio se aprecia un
ajuste en el consumo de recursos que este presentará. Correctamente dimensionado se ahorra
un 50% de espacio de disco asignado y calculando el 90 percentil de los máximos se obtienen
valores mucho menores y más reales del comportamiento de servicio en un día típico.
3.3.4 Requerimiento de Capacidades para ofrecer IaaS.

En estos momentos no se planea brindar IaaS, pero en un futuro sí. Para ello utilizar la Tabla 18
del Epígrafe 2.4.4 cuando sea necesario.
3.4. Requerimientos no funcionales del SA.

A continuación, se aplicó la encuesta que se propuso en el Epígrafe 2.5 para conocer los RNF
que deberá cumplir el SA:
83
Datos”
1- Seleccione de las siguientes categorías cuál desea que posea una mayor prioridad. Se deberá
asignar una numeración ascendente donde los números más bajos representan mayor
prioridad comenzando por 1. En caso de que no sea importante su prioridad dejar en blanco.
_4_Escalabilidad _6_Compatibilidad _1_Desempeño _2_Disponibilidad _8_Usabilidad

_5_Robustez _3_Factibilidad _7_Seguridad
económica
2- En cuanto a escalar horizontalmente, ¿cuál de los siguientes aspectos representa una
problemática? Se deberá asignar una numeración ascendente donde los números más bajos
representan mayor criticidad comenzando por 1. En caso de que no sea una problemática
dejar en blanco.
_9_Restricciones de localización: Ej.: deben evitarse locales que limiten la expansión por su
cercanía con componentes de la edificación como elevadores, muros exteriores, etc.
_3_Restricciones de espacio: Es necesario verificar el espacio asignado para el SA para así poder
conocer las dimensiones del servidor a comprar y poder escalar de forma óptima.
_7_Restricciones arquitectónicas: Ej.: la altura mínima del cuarto debe ser de 2.6m desde el piso
hasta cualquier obstrucción superior como lámparas, cámaras, rociadores, etc.
_5_Restricciones de armarios/bastidores: Los armarios/bastidores deben estar dispuestos de tal

manera que sus partes delanteras queden frente a las partes delanteras de otra fila de
armarios/bastidores formando pasillos “fríos” y pasillos “calientes”. La distancia entre las partes
delanteras del equipamiento debe ser 1m como mínimo. Se recomiendan distancias de 1.2m.
La distancia entre partes traseras del equipamiento debe ser de 0.6m como mínimo. Se
recomiendan distancias de 1m. La altura máxima debe ser de hasta 2.4m y su profundidad de
hasta 1.1m.
_8_Restricciones medioambientales: Ej.: Si el cuarto no tiene un sistema de HVAC25 dedicado,
entonces debe estar localizado en un lugar que tenga acceso al sistema HVAC principal de la
edificación.
_2_Restricciones eléctricas: Ej.: La alimentación debe venir por parte de circuitos separados que
terminen en sus paneles eléctricos. Los tomacorrientes de 120V y 20A deben estar ubicados a
lo largo de las paredes del cuarto de cómputo con una separación de 3.65m entre ellos.
_6_Restricciones de consumo eléctrico: Aunque por las restricciones de la TIA, de la red y del SA
un CD tenga cierta escalabilidad horizontal, puede suceder que esa escalabilidad no sea factible
porque se sobre pase el límite de consumo de energía eléctrica que tiene planificado el CD, o
porque signifique una inversión que no es viable acometer.
_4_Restricciones de topologías de red: En función de la topología de red, su capacidad, las
características de los dispositivos de interconexión, los protocolos y la configuración, será el
número de servidores que podrá ser soportado.
25
Siglas correspondientes al término en Inglés: Heating, Ventilation, and Air Conditioning
84
Datos”
_1_Restricciones de presupuesto: La escalabilidad puede estar limitada por el presupuesto

asignado para el SA por lo que es necesario conocer de cuánto se dispone para futuras compras
de equipamiento.
3- En cuanto a la flexibilidad del SA, este deberá:

_X_Tener soporte de pluggins _X_Tener facilidad de integración con herramientas de terceros
_X_Ser una solución SLCA modificable por el cliente.
4- En cuanto a compatibilidad:
¿Qué sistema operativo se utilizará con la solución?
R/Sistema Operativo Linux
¿Qué gestor se empleará?
R/Gestor OpenNebula
5- En cuanto a capacidad:
¿Qué espacio en GB deberá asignarse a utilizar por las instancias virtuales en total? ¿Qué nivel de
redundancia deberá tener?
R/ 1TB con redundancia 3
¿Qué espacio en GB deberá asignarse para las salvas? ¿Qué nivel de redundancia deberá tener?
R/1 TB con erasure code
¿Qué espacio en GB deberá asignarse para ofrecer DSaaS? ¿Qué nivel de redundancia deberá
tener?
R/ 500 GB con redundancia 2
6- En cuanto al % de servicio activo, se tomará en cuenta el tiempo de mantenimiento:

__SI _X_NO
7- En cuanto a la usabilidad que poseen los administradores para gestionar responda las
siguientes interrogantes:
¿Cómo califican la facilidad de instalación del sistema? __Buena _X_Mala __Regular
¿Cómo califican la curva de aprendizaje de gestión del sistema? __Fácil __Medio _X_Difícil
¿Cómo califican las opciones de gestión del sistema (Web, CLI, Otra Herramienta)?
__Buena _X_Mala __Regular
8- En cuanto a la robustez de la solución, ¿qué aspectos se consideran prioritarios para su

selección? Se deberá asignar una numeración ascendente donde los números más bajos
representan mayor criticidad comenzando por 1.
En cuanto al Hardware tanto de red como de servidores del SA:
_3_Años en el mercado _2_Ranking Mundial _1_Costos _4_Variedad de Soporte
85
Datos”
En cuanto a la solución de software del SA y salvas:

_2_Ranking mundial _4_Roadmaps _1_Índice de penetración _3_Variedad de Soporte
3.5. Caracterización del SA inicial

La Universidad no contaba con un SA desplegado. El almacenamiento existente era tipo DAS
empleando a Proxmox como gestor. Al no existir alta disponibilidad de MV al ocurrir una falla
en un nodo provocaba la caída del servicio. En caso de rotura en un nodo, la operación consistía
en levantar una salva de la instancia o instancias virtuales afectadas en otro nodo. Dicho
almacenamiento no respondía a los requerimientos de disponibilidad necesarios para mantener
una correcta calidad de servicio a los usuarios, por lo que en ocasiones se veían afectados
servicios básicos como: correo electrónico y navegación web.
3.6. Definición del SA a desplegar

Por lo antes planteado se hizo necesario el despliegue de un SA que respondiera a los RNF
necesarios para ofrecer un servicio de calidad. Para ello se siguió el procedimiento propuesto
en el Epígrafe 2.7.
El primer paso consistía en comprobar si existe como restricción el empleo de un SA en

particular. Dicha interrogante tuvo respuesta NO en la encuesta correspondiente a las
regulaciones y/o políticas. Por tanto, se procedió a la selección de una solución SLCA.
Dada las aplicaciones que utilizarán el SA el autor propuso utilizar el sistema de almacenamiento
SAN Ceph. Ceph File System es un sistema de archivos distribuido libremente, está diseñado
para el uso con gran cantidad de datos. Ceph tiene como objetivo ser compatible con POSIX y
completamente distribuido sin ningún punto de fallo. Los datos tienen replicación libre de
errores, haciéndolo tolerante a fallos.
Entre los usuarios de Ceph se encuentran grandes compañías de prestigio internacional como
Cisco, Western Digital, ZTE y T-Mobile de Alemania. Además, sus requerimientos de Hardware
son bajos lo que permite su despliegue en Hardware de propósito general (ANEXO M).
Para las pruebas preliminares se utilizaron las mismas definidas en el Epígrafe 2.10.
3.7. Diseño Lógico

Luego de conocer el SA a desplegar sigue su diseño lógico. Para ello se siguió el procedimiento
propuesto en el Epígrafe 2.8.1. Por motivos de tiempo no se pudo validar el diseño del sistema
de salvas ni el de DSaaS así que el diseño lógico solamente tendrá reflejado al SA en sí, no en su
conjunto.
1.Identificar las recomendaciones de diseño lógico propuesta por el proveedor
Según la documentación oficial de Ceph esta propone dos subredes: 1- Red Cliente: es la
utilizada por las instancias virtuales o los elementos que utilizarán el SA y debe tener un ancho
86
Datos”
de banda mínimo de 1Gbps, 2- Red del Clúster: es la empleada para las acciones de replicación
y balanceo del clúster y es recomendado un ancho de banda de 10Gbps.
2.Proyectar el diseño lógico de los nodos de cómputo, control, red del sistema y gestión.
En este caso los nodos de cómputo son los monitores que son los encargados de mantener el
mapa del estado del clúster, incluyendo el mapa del monitor, el mapa OSD, el mapa del Grupo
de Colocación (PG) y el mapa CRUSH. Ceph mantiene una historia (llamada "epoch") de cada
cambio de estado en los Ceph Monitors, Ceph OSD Daemons y PGs. En cuanto a los nodos de
control puede ser cualquiera que pertenezca al clúster Ceph.
En cuanto a la red todas las redes en la CUJAE están virtualizadas mediante el uso de Redes de
Área Local Virtuales (VLAN), por esta razón todas las subredes utilizadas en el SA contienen
además de los parámetros básicos que identifican una red, el identificador de VLAN
correspondiente asignado por los administradores del centro para la red del clúster y un troncal
LACP para la red cliente. Los nodos utilizan una red pública para atender las peticiones de los
clientes, esta es la que posee un troncal LACP con dirección de red 10.8.9.0/24 con el objetivo
de llegar a un ancho de banda de 2Gbps. También se emplea una red interna para el clúster
donde se realizan las operaciones de réplica de los diferentes objetos almacenados, esta red es
la VLAN 4002, con dirección de red 192.168.0.0/24. El conmutador utilizado para interconectar
estas redes posee todas sus interfaces a con un ancho de banda de 1 Gbps.
El SA debe contar con una parte destinada a la monitorización y gestión del servicio según dicta
la arquitectura de referencia de la UIT. Esta monitorización debe permitir comprobar el estado
de todos los componentes que forman parte del sistema con el objetivo de prevenir
proactivamente cualquier fallo que pudiera ocasionarse. Debe ser capaz de enviar
notificaciones reportando cualquier evento del sistema, así como debe permitir la fácil
configuración de cualquier componente. El SA también debe contar con algún mecanismo de
autenticación para garantizar el nivel de seguridad y privacidad de la información necesarios
frente a accesos no autorizados. En cuanto a lo anterior, el cli de Ceph permite cubrir 3 de las 5
áreas: Configuración, Prestaciones y Seguridad. Por lo que se hizo necesaria la utilización de una
Herramienta de Gestión (HG), por lo que se empleó Zabbix para cubrir las restantes: Fallas y
Contabilidad. La gestión se realiza por la red cliente ya que el volumen de información no
dificulta el tráfico con las aplicaciones que utilizan el SA.
87
Datos”
El diseño fue el siguiente:
Figura 22 Diseño Lógico del SA Ceph
3.Identificar los Requerimientos de Hardware sugeridos por el proveedor
Según la documentación oficial Ceph se identificó que el hardware debe cumplir con:
Procesador: Dual Core
RAM: 1GB por OSD
Red:2 interfaces de Red: 1-Red cliente a un mínimo de 1Gbps y 2- Red Clúster sugerido a
10Gbps.
4.Identificar la capacidad de almacenamiento requerida de forma particular
Para ello se utilizó la Tabla 25 propuesta en el Epígrafe 2.8.1. Para ello se tomaron las
respuestas de la encuesta realizada en el Epígrafe 3.2.
Tabla 25 Resultados de Capacidades Totales a Soportar por el SA
Cómputo
Red Requerida
Capacidad en Necesario
Factor de
Sistema Nodo GB sin Número Ancho de
Redundancia
redundancia de banda CPU RAM
interfaces requerido
Salvas - 1000 Erasure code - - - -
DSaaS - 500 2 - - - -
SA Ceph01 3000 - 2 4 GB
88
Datos”
Ceph02 3000 - 2 Cliente:

Ceph03 3000 - 2 1Gbps Dual
Ceph04 3000 - 2 Clúster: 10 Core
Ceph05 3000 - 2 Gbps
Para el cálculo de la capacidad final que deberá soportar el SA el autor utilizó las fórmulas 2 y 3
propuesta en el Epígrafe 2.8.1
𝐶𝑎𝑝𝑎𝑐𝑖𝑑𝑎𝑑 𝑇𝑜𝑡𝑎𝑙 𝑑𝑒𝑙 𝑆𝐴 𝑅𝑒𝑞𝑢𝑒𝑟𝑖𝑑𝑎

= 𝐶𝑎𝑝𝑎𝑐𝑖𝑑𝑎𝑑 𝑇𝑜𝑡𝑎𝑙 𝑝𝑎𝑟𝑎 𝑆𝑎𝑙𝑣𝑎𝑠 ∗ 𝐹𝑎𝑐𝑡𝑜𝑟 𝑑𝑒 𝑟𝑒𝑑𝑢𝑑𝑎𝑛𝑐𝑖𝑎
+ 𝐶𝑎𝑝𝑎𝑐𝑖𝑑𝑎𝑑 𝑇𝑜𝑡𝑎𝑙 𝐷𝑆𝑎𝑎𝑆 ∗ 𝐹𝑎𝑐𝑡𝑜𝑟 𝑑𝑒 𝑟𝑒𝑑𝑢𝑛𝑑𝑎𝑐𝑖𝑎
𝐶𝑎𝑝𝑎𝑐𝑖𝑑𝑎𝑑 𝑇𝑜𝑡𝑎𝑙 𝑑𝑒𝑙 𝑆𝐴 𝑅𝑒𝑞𝑢𝑒𝑟𝑖𝑑𝑎 = 1000 + 500 ∗ 2 = 2000 𝐺𝐵
𝐶𝑎𝑝𝑎𝑐𝑖𝑑𝑎𝑑 𝐷𝑖𝑠𝑝𝑜𝑛𝑖𝑏𝑙𝑒
= 𝐶𝑎𝑝𝑎𝑐𝑖𝑑𝑎𝑑 𝑇𝑜𝑡𝑎𝑙 𝑑𝑒𝑙 𝑆𝐴 − 𝐶𝑎𝑝𝑎𝑐𝑖𝑑𝑎𝑑 𝑇𝑜𝑡𝑎𝑙 𝑑𝑒𝑙 𝑆𝐴 𝑅𝑒𝑞𝑢𝑒𝑟𝑖𝑑𝑎
𝐶𝑎𝑝𝑎𝑐𝑖𝑑𝑎𝑑 𝐷𝑖𝑠𝑝𝑜𝑛𝑖𝑏𝑙𝑒 = 1500 − 2000 = 1300 𝐺𝐵
3.8. Diseño Físico

Luego de conocer el diseño lógico a desplegar sigue su diseño físico. Para ello se siguió el
procedimiento propuesto en el Epígrafe 2.8.2.
1.Valorar las condiciones físicas del local
El SA se desplegó en un local cuyas dimensiones aproximadas son de unos 5 metros de ancho x

8 metros de largo por lo que existe una restricción evidente a la hora de escalar en un futuro el
SA. Lo recomendable en espacios pequeños sería rack pero el diseño se realizó con Hardware
heredado por lo que se utilizó torre.
En cuanto a climatización el local posee 3 Splits los cuales garantizan la temperatura requerida,
así como un deshumidificador.
El lugar no presenta problemas en cuanto al tema eléctrico y cada servidor posee su backup
además de que existe una planta externa en caso de algún fallo en el fluido eléctrico.
En cuanto a la seguridad del local existe un sistema de alarmas, así como una lista de personas
autorizadas a acceder al mismo.
Adicionalmente, el local presenta extintores, como mecanismo de protección ante algún

desastre, en este caso, un incendio.
2. ¿Existe un hardware inicial?
Sí, el CD poseía hardware heredado de servicios anteriormente desplegados y que ya no estaban

en producción.
3. Análisis o no de la utilización del hardware inicial
89
Datos”
El hardware inicial cumplía con el diseño lógico propuesto por el proveedor.
4.Requerimientos de Hardware y Capacidad
Con respecto al Hardware, sí cumplía con lo propuesto por el proveedor, pero en cuanto a
capacidad total no cumplía con los requisitos.
5. Agregar componente extra
Ya que la capacidad no era la indicada, se agregaron más discos duros logrando una capacidad
por nodo de 3 TB. Además, en cuanto a la red se agregaron en cada nodo dos tarjetas de red a
1 Gbps para lograr un enlace LACP de 2Gbps en la red cliente. Dichos componentes son de
tecnología moderna por lo que resultó factible su agregación.
6.Documentar la solución final

Finalmente, el diseño físico quedo de la siguiente forma:
Datos de Hardware
Tabla 26 Resumen del Hardware empleado en el SA
Nodos CPU, número de RAM (GB) HDD (GB) Interfaces de Red

núcleos
Ceph01 Intel Core i3 2130 8 160+ 3x1024 3
(3,4 Ghz), 4
núcleos
(3,4 Ghz), 4
núcleos
(3,4 Ghz), 4
núcleos
(3,4 Ghz), 4
núcleos
(3,2 Ghz), 4
núcleos
Tipo de cableado utilizado: UTP categoría 5
Switchs:
Se utilizaron 2 Switchs:
1.
Marca: Allied Telesis AT-9424T/SP.

Cantidad de Puertos:24 puertos
Velocidades Compatibles: 10/100/1000TX
Cantidad de Vlans: 4K VLANs
Gestión: SNMP y RMON
Datasheet: https://www.alliedtelesis.com/sites/default/files/9400_series_ds_revp.pdf
2.
Marca: Cisco Catalyst 2960G-24TC-L Switch

Cantidad de Puertos:24 puertos
90
Datos”
Velocidades Compatibles: 10/100/1000TX

Cantidad de Vlans: 4K VLANs
Gestión: SNMP y RMON
Datasheet: http://www.cisco.com/c/en/us/products/collateral/switches/catalyst-2960-series-
switches/product_data_sheet0900aecd80322c0c.html
Esquemático:
Figura 23 Diseño Físico del SA Ceph
Leyenda:
Enlaces LACP A-J: Red Cliente K-Ñ: Red del Clúster
Interfaz Switch Puerto

A Switch 03 20
B Switch 03 18
C Switch 03 15
D Switch 03 10
E Switch 03 16
F Switch 03 13
G Switch 03 7
H Switch 03 17
I Switch 03 22
J Switch 03 5
K Switch 04 8
L Switch 04 12
M Switch 04 15
N Switch 04 10
Ñ Switch 04 3
Finalmente se procedió a la creación de la guía de despliegue la cual se encuentra en el ANEXO

O.
3.9. Resultados de las Pruebas al SA

Para las pruebas se siguió el modelo propuesto en el Epígrafe 2.10. y se tomó como muestra al Nodo
Ceph05.
91
Datos”
PRUEBA #1
Troughtput e IOPS HDD

200 5000
180 4500
160 4000
Troughtput (MB/s)
140 3500
120 3000
IOPS
100 2500
80 2000
60 1500
40 1000
20 500
0 0
Troughtput IOPS
Figura 24 Throughput e IOPS de lectura y escritura de los discos duros
Troughtput e IOPS CLUSTER CEPH

250 12000
10000
Troughtput (MB/s)
200
8000
150
IOPS
6000
100
4000
50 2000
0 0
Troughtput IOPS
Figura 25 Throughput e IOPS de lectura y escritura del clúster Ceph
Comentario: Como se puede observar el comportamiento en clúster es similar al de los discos

de forma independiente, pero mejorando considerablemente el desempeño y las operaciones
a realizar.
92
Datos”
Tabla 27 Throughput de la Red Cliente Interfaz 1
Tabla 28 Throughput de la Red Cliente Interfaz 2

CEPH
CEPH
Ceph01 Ceph02 Ceph03 Ceph04
Ceph01 940/112 941/112 944/112
Ceph01 942/111 940/112 942/112
Ceph02 941/112 941/112 941/112
Ceph02 940/110 941/110 941/111
Ceph03 946/112 943/112 940/112
Ceph03 942/110 945/111 940/112
Ceph04 942/112 941/112 942/112
Ceph04 941/112 943/111 942/112
Unidades
Unidades
Mbit/s | Mbyte/s
Mbit/s | Mbyte/s
Tabla 29 Throughput de la Red Clúster
CEPH
Ceph01 951/112 943/110 942/112
Ceph02 940/110 943/112 940/111
Ceph03 940/110 944/112 940/112
Ceph04 941/112 940/111 941/112
Unidades
Mbit/s | Mbyte/s
Comentario: El resultado es el esperado ya que cada interfaz de red es a 1Gbps.
PRUEBA #2
Latencia (ms) HDD

60
50
40
30
20
10
Latencia (milisegundos)
Figura 26 Latencias de los Discos empleados en el SA
93
Datos”
Latencia (ms) CEPH

1
0,9
0,8
0,7
0,6
0,5
0,4
0,3
0,2
0,1
0
Latencia (ms)
Figura 27 Latencias del SA en clúster
Comentario: En cuanto a las latencias podemos observar que para un disco físico y para la
mayoría de los tamaños de bloques se encuentra por debajo de los 30 ms que es un poco por
encima del umbral establecido, pero aun así sigue siendo un buen resultado. En cambio, al
aplicar la prueba al SA vemos un cambio radical, siendo la latencia mayor 1ms.
PRUEBA #3
Los nodos empleados se agregaron con éxito al sistema aumentando la capacidad de

almacenamiento disponible del mismo. Durante las operaciones realizadas no se detectaron
falla en el funcionamiento del SA y la información contenida no sufrió alteración alguna.
Esta prueba solo se ejecutó parcialmente debido a que solo se pudo comprobar la capacidad
del sistema para añadir más nodos, no se pudo comprobar cómo funciona con una capacidad
de almacenamiento del orden del exabyte, pues el centro no cuenta con una infraestructura de
esas dimensiones.
PRUEBA #4
Tabla 30 Tabla de Resultados Prueba de Estrés
CPU RAM Red Red Carga Clúster

Cliente Clúster
Escritura Lectura IOPS
Valor 8 GB 2 Gbps 1 Gbps 200 MB/s 190 MB/s 15000
Utilización 40% 50 % 10% 20% 48% 35% 75%
(%)
Comentario: En cuanto a las pruebas de estrés permitió conocer las potencialidades que puede
ofrecer Ceph en un entorno de gran utilización del SA. Aun así, pudo responder
satisfactoriamente utilizando, en la mayoría de los casos menos del 50% de los recursos totales.
94
Datos”
PRUEBA #5
Durante este período de tiempo el SA no estuvo fuera de servicio. En todos los casos en que
fueron provocadas intencionalmente las fallas el SA activó el mecanismo de auto rebalanceo de
la información al detectar el fallo en algunos de sus componentes, y logró añadirlos nuevamente
cuando fueron reinsertados. Durante estas operaciones el servicio no sufrió ninguna pérdida
apreciable en la QoS brindada a los clientes y la información almacenada previamente no sufrió
ninguna alteración manteniéndose la integridad de la misma. Esto ofrece un porcentaje de
disponibilidad equivalente a un 100%.
PRUEBA #6
Tabla 31 Tabla de Resultados Prueba de Utilización
CPU RAM Red Red Carga Clúster

Cliente Clúster
Escritura Lectura IOPS
Valor 8 GB 2 Gbps 1 Gbps 200 MB/s 190 MB/s 15000
Utilización 10% 45% 2% 3% 13.5% 2.4% 30%
(%)
Comentario: A diferencia de la prueba de estrés en un entorno típico vemos que el SA realiza

muy poca utilización de los recursos, permitiendo así conocer que puede soportar aún más
carga sin llegar a afectar a las aplicaciones que sobre este corren en estos momentos. Es decir
que aún puede agregárseles nuevas aplicaciones.
PRUEBA #7
No se realizó ya que no se contaba ni con el software ni con los instrumentos de medición requeridos.
3.10. Conclusiones
La implementación del método propuesto permitió certificar su validez y eficacia en la práctica.
La solución de software empleada fue el SDS distribuido Ceph, el cual cumplió con la mayoría
de los requerimientos pues permitió ser desplegado tanto sobre hardware de propósito general
ofreciendo resultados positivos en la mayoría de las pruebas realizadas. La usabilidad de los
administradores resultó ser el requerimiento más negativo del SA debido a la ausencia de una
interfaz gráfica intuitiva y al nivel de conocimientos necesarios para gestionar el SDS.
95
Conclusiones
CONCLUSIONES
El método desarrollado para el diseño de SA constituye una posible solución económica, eficaz
y segura para las infraestructuras TIC de las pequeñas y medianas empresas, dotándolas de una
infraestructura dinámica con un nivel de escalabilidad capaz de responder rápidamente a la
demanda de los servicios y aplicaciones que estas posean. Posibilita diseñar SA basados en las
condiciones particulares de los CD privados de las empresas, permitiendo un mejor
aprovechamiento de los recursos financieros y de cómputo del centro, contribuyendo al
cumplimiento de los objetivos del negocio. Las pruebas de validación diseñadas en el método
permiten evaluar el cumplimiento de los RNF definidos al inicio del proceso de diseño una vez
desplegado el SA inicial, lo que permite detectar futuras fallas que puedan afectar el
rendimiento del SA. El empleo del método en el diseño del SA de la CUJAE permitió validar su
desempeño, pues se logró la confección de un SA capaz de ofrecer una respuesta efectiva a las
necesidades y condiciones existentes, hecho que se pudo constatar mediante el cumplimiento
de los RNF propuestos.
96
Recomendaciones
RECOMENDACIONES
 Solucionar los problemas asociados a las restricciones existentes para el diseño del
sistema de almacenamiento en la CUJAE.
 Mantener vigilancia sobre la futura plataforma de gestión de Ceph Kraken para mejor
la usabilidad del SA
 Actualizar la versión de Ceph empleada cada cierto tiempo
 Implementar el servicio de Salvas usando Bácula.
 Implementar en forma de prueba de campo el servicio de DSaaS usando Pydio.
 Implementar el método caracterizando el 100% de las aplicaciones.
97
Referencias bibliográficas
REFERENCIAS BIBLIOGRAFICAS
[1] P. Oppenheimer, Top-down network design, 3rd ed. Indianapolis, IN: Cisco Press, 2011.
[2] R. J. Kauffman, D. Ma, and M. Yu, “A metrics suite of cloud computing adoption readiness,”
Electron. Mark., pp. 1–27, 2016.
[3] F. Tarrau Prendes, L. R. García Perellada, and Garófalo Hernández, “PROPUESTA DE

REQUERIMIENTOS NO FUNCIONALES PARA EL DISEÑO Y EVALUACIÓN DE NUBES PRIVADAS CON
SOPORTE PARA INFRAESTRUCTURA COMO SERVICIO,” in 18 Convención Científica de Ingeniería y
Arquitectura., Palacio de Convenciones de La Habana, 2016, pp. 881–895.
[4] J. Zhu, “Cloud Computing Technologies and Applications,” in Handbook of Cloud Computing,
B. Furht and A. Escalante, Eds. Boston, MA: Springer US, 2010, pp. 21–45.
[5] “Cisco Enterprise Networks - Products,” Cisco. [Online]. Available:

http://www.cisco.com/c/en/us/solutions/enterprise-networks/product-listing.html. [Accessed: 27-
Jan-2017].
[6] “Flash Storage – SAN Storage and Hybrid Storage Products | NetApp.” [Online]. Available:
http://www.netapp.com/us/products/index.aspx. [Accessed: 27-Jan-2017].
[7] “IBM Storage Networking: Fibre Channel Storage Area Networks (SAN),” 20-Jul-2011. [Online].
Available: http://www.ibm.com/systems/storage/san/. [Accessed: 27-Jan-2017].
[8] “Network Devices,” Dell. [Online]. Available: http://www.dell.com/us/business/p/networking-

products. [Accessed: 27-Jan-2017].
[9] “Architecting a High Performance Storage System,” Jan. 2014.
[10] J. Tate, R. Kelley, S. R. R. Maliska, L. Torolho, M. Voigt, and others, IBM SAN Solution Design
Best Practices for VMware vSphere ESXi. IBM Redbooks, 2013.
[11] “IEEE Xplore Digital Library.” [Online]. Available: http://ieeexplore.ieee.org/Xplore/home.jsp.

[Accessed: 20-Apr-2017].
[12] “Home - Springer.” [Online]. Available: http://rd.springer.com/. [Accessed: 20-Apr-2017].
[13] “ACM Digital Library.” [Online]. Available: https://dl.acm.org/. [Accessed: 20-Apr-2017].
[14] Cisco Corp., “Advanced SAN Design Using Cisco MDS 9500 Series Multilayer Directors - Cisco.”
04-Jan-2014.
[15] V. Stewart, M. Slisinger, L. Touchette, and P. Learmonth, “NetApp and VMware vSphere
Storage Best Practices,” 2010.
[16] E. C. Microsoft Corp, “MICROSOFT EXCHANGE STORAGE BEST PRACTICES AND DESIGN
GUIDANCE FOR EMC STORAGE,” 2012. [Online]. Available:
http://www.ndm.net/emcstore/pdf/vnx/h8888-exch-2010-storage-best-pract-design-guid-emc-
storage.pdf. [Accessed: 06-Feb-2017].
[17] “SAN Design and Best Practices,” 2015.
[18] “Storage best practices snia,” 24-Jan-2017. [Online]. Available:

http://www.snia.org/sites/default/education/tutorials/2011/spring/file/Anjan_Dave_Storage_Mgmt_
Spring_2011.pdf. [Accessed: 24-Jan-2017].
[19] SNIA, “Storage Considerations in Data-Center Design,” 2012. [Online]. Available:

http://www.snia.org/sites/default/files/StorageConsiderationsinDataCenterDesign.pdf. [Accessed:
18-Jan-2017].
[20] R. K. Randy Kerns, “Storage Strategy Development,” presented at the SNIA: Data Storage
Innovation Conference, 2015.
[21] ARISTA, “Deploying_Storage_Networks,” 2016. [Online]. Available:

https://www.arista.com/assets/data/pdf/Whitepapers/Deploying_Storage_Net_WhitePaper.pdf.
[Accessed: 18-Jan-2017].
98
[22] Australian Goverment, “Design a spatial-data storage system,” 2012. [Online]. Available:
https://training.gov.au/TrainingComponentFiles/CPP07/CPPSIS5043A_R1.pdf. [Accessed: 20-Jan-
2017].
[23] “Dayron Albeirus Padrón, Lilia Rosa García Perellada, David Ferrat Garea ‘PROPUESTA DE UN
MÉTODO PARA EL DISEÑO DE SISTEMAS DE ALMACENAMIENTO PARA CENTROS DE DATOS,’ in 18
Convención Científica de Ingeniería y Arquitectura., Palacio de Convenciones de La Habana, 2016, pp.
896–907.” .
[24] A. Santoyo González, L. R. García Perellada, and A. A. Garófalo Hernández, “PROPUESTA DE

UNA ARQUITECTURA DE ALMACENAMIENTO PARA NUBES PRIVADAS QUE SOPORTEN
INFRAESTRUCTURA COMO SERVICIO (IAAS1),” Rev. Telemtica, vol. 11, no. 3, pp. 68–82, Sep. 2012.
[25] Microsoft, “Infrastructure-as-a-Service Product Line Architecture.” 2016.
[26] “Documentation - Ceph.” [Online]. Available: http://docs.ceph.com/docs/master/. [Accessed:

20-Apr-2017].
[27] “Documentation - GlusterFs.” [Online]. Available:

http://gluster.readthedocs.io/en/latest/Quick-Start-Guide/Quickstart/. [Accessed: 20-Apr-2017].
[28] “Documentation - FreeNas.” [Online]. Available:

https://wiki.freenas.org/index.php/Main_Page. [Accessed: 20-Apr-2017].
[29] “Documentation - Openfiler.” [Online]. Available:

https://downloads.sourceforge.net/project/openfiler/Documentation/OpenfilerAdminGuide2.9x-
with-iscsi.pdf?r=&ts=1492696707&use_mirror=superb-dca2. [Accessed: 20-Apr-2017].
[30] “Documentation - OpenNebula.” [Online]. Available:

https://opennebula.org/documentation/. [Accessed: 20-Apr-2017].
[31] “Documentation - OpenStack.” [Online]. Available: https://docs.openstack.org/. [Accessed:

20-Apr-2017].
[32] “Storage Server Archives,” Inspur. [Online]. Available:

http://www.inspursystems.com/products/storage-server/. [Accessed: 20-Apr-2017].
[33] “Servers | Huawei Enterprise.” [Online]. Available:

https://www.huaweienterpriseusa.com/rack-servers. [Accessed: 20-Apr-2017].
[34] “J. F. Kurose and K. W. Ross, Computer networking : a top-down approach, 6ta. United States
of America: Pearson Education, Inc., 2013.” .
[35] “‘AWS | Amazon EC2 | Tipos de instancias,’ Amazon Web Services, Inc. [Online]. Available:
//aws.amazon.com/es/ec2/instance-types/. [Accessed: 08-Jul-2015].” .
[36] “‘Tamaños de máquina virtual.’ [Online]. Available: https://azure.microsoft.com/es-

es/documentation/articles/virtual-machines-size-specs/. [Accessed: 30-Sep-2015].” .
[37] Vmware, “Server and Storage Sizing For VMware VDI: A Prescriptive Approach.” 2016.
[38] Ramírez, José Guillermo Gil, “Propuesta de pruebas para evaluar desempeño y elasticidad de
Nubes Privadas con soporte para la capacidad de Infraestructura como Servicio,” Instituto Superior
Politécnico José Antonio Echeverría, 2016.
[39] Herrera Matos, Carlos José, “Propuesta de pruebas para evaluar sistemas de
almacenamiento,” Instituto Superior Politécnico José Antonio Echeverría, 2015.
[40] Asiel Lara Brito, “Diseño del Sistema de Almacenamiento de Copias de Seguridad de la Red-
CUJAE,” Instituto Superior Politécnico José Antonio Echeverría, 2015.
[41] “EMC Product-warranty,” 16-May-2017. [Online]. Available:

https://www.emc.com/collateral/warranty-maintenance/h4276-emc-prod-warranty-maint-table.pdf.
[Accessed: 16-May-2017].
99
[42] “End of Service and Support Announcement for OceanStor N8300 - Enterprise Service
Support,” 16-May-2017. [Online]. Available: http://support.huawei.com/enterprise/en/bulletins-
product/NEWS1000010411. [Accessed: 16-May-2017].
[43] “IBM Support - IBM software support lifecycle policy,” 27-Feb-2017. [Online]. Available:
https://www-01.ibm.com/software/support/lifecycle/lc-policy.html. [Accessed: 16-May-2017].
[44] “Life cycle announcement strategy - Enterprise Service Support,” 16-May-2017. [Online].
Available:
http://support.huawei.com/enterprise/NewsReadAction.action?newType=0304&contentId=NEWS10
00002017. [Accessed: 16-May-2017].
[45] “Obsolescence & Migrations - HPE Software Support,” 16-May-2017. [Online]. Available:
https://softwaresupport.hpe.com/obsolescence-migrations. [Accessed: 16-May-2017].
[46] “Service & Warranty Support,” Inspur, 16-May-2017. .
[47] ITU Telecommunication Standardization, “Cloud computing infrastructure requirements,”

ITU-T, Switzerland Geneva, Recommendation ITU-T Y.3510 ITU-T Y.3510, 2014.,” ITU-T Recomm.,
2016.
[48] “SNIA. Cloud Storage Reference Model,” 2017.
[49] G. Perellada, L. Rosa, and A. A. Garófalo Hernández, “Arquitectura de Referencia para el

diseño y despliegue de Nubes Privadas,” Ing. Electrónica Automática Comun., vol. 36, no. 1, pp. 1–16,
2015.
[50] “G. Kandiraju, H. Franke, M. D. Williams, M. Steinder, and S. M. Black, ‘Software defined
infrastructures,’ IBM J RES DEV, vol. 58, no. 2/3, p. 13, 2014.” .
[51] “L. R. García Perellada and A. A. Garófalo Hernández, ‘Arquitectura de Referencia para el
diseño y despliegue de Nubes Privadas,’ Rev. Ing. Electrónica Automática Comun. RIELAC, vol. XXXVI,
no. 1/2015, pp. 33–38, Enero - Abril 2015.” .
[52] “‘Cloud computing – Functional requirements of Infrastructure as a Service,’ ITU-T,

Switzerland Geneva, Recommendation ITU-T Y.3513 Y.3513, Aug. 2014.” .
[53] “L. E. Nelson, ‘The Forrester WaveTM: Private Cloud Software Suites, Q1 2016. How The Top
Nine Private Cloud Software Suites Stack Up.,’ Forrester Research, Inc., 60 Acorn Park Drive,
Cambridge, MA 02140 USA, Q1 2016, Jan. 2016.” .
[54] “‘ast-0066982_iw_private_cloud_final.pdf.’” .
[55] “‘Requirements for desktop as a service,’ ITU-T, Switzerland Geneva, CLOUD COMPUTING
Y.3500–Y.3999 ITU-T Y.3503, May 2014.” .
[56] “‘Cloud computing – Functional requirements of Network as a Service,’ ITU-T, Switzerland

Geneva, Recommendation ITU-T Y.3512 Y.3512, Aug. 2014.” .
[57] “‘The next-generation data center,’ IBM Corporation, USA, May 2014.” .
[58] “R. Mahindru, R. Sarkar, and M. Viswanathan, ‘Software defined unified monitoring and
management of clouds,’ IBM J RES DEV, vol. 58, no. 2/3, p. 12, 05 2014.” .
[59] “L. Xu, L. Liu, and C. Wu, ‘Services Enhancing Usage of Large Equipments in a Private Cloud,’ in
2013 International Conference on Service Sciences (ICSS), 2013, pp. 118–122.” .
[60] “‘Cloud computing framework and high-level requirements,’ ITU-T, Switzerland Geneva,
Recommendation ITU-T Y.3501 Y.3501, May 2013.” .
[61] “‘Information technology – Cloud computing – Reference architecture,’ ISO copyright office,
Switzerland, ISO/IEC 17789:2014 (E), 10 2014.” .
[62] “F. Cocozza, G. López, G. Marín, R. Villalón, and F. Arroyo, ‘Cloud Management Platform
Selection: A Case Study in a University Setting,’ in CLOUD COMPUTING 2015, Nice, France, 2015, pp.
77–85.” .
100
[63] “‘Cloud computing framework and high-level requirements,’ TELECOMMUNICATION

STANDARDIZATION SECTOR OF ITU, Switzerland Geneva, Recommendation Recommendation ITU-T
Y.3501, 2014.” .
[64] “Bertogna ML: Planificación Dinámica sobre Entornos Grid. Universidad Nacional de La Plata,
Facultad de Informática; 2010.” .
[65] John Rath and Rath Consulting, “DATA CENTER STRATEGIES. Simplifying high-stakes, mission
critical decisions in a complex industry.”
[66] S. Overby, “6 IT Strategies to Stay Ahead of Data Center Trends,” CIO, 07-Mar-2014. [Online].
Available: http://www.cio.com/article/2378095/data-center/6-it-strategies-to-stay-ahead-of-data-
center-trends.html. [Accessed: 23-May-2017].
[67] “Buckle P: How to Configure Openfiler iSCSI Storage for VMware ESX 4. Xtravirt; 2009.” .
[68] “Byrne J: Where is the cloud storage market headed? In Storage, vol. 10. pp. 3; 2011:3.” .
[69] “Campello D: Network File System. Venezuela: Universidad Simón Bolívar; 2007.” .
[70] “Castagna R: Storage budget recovery on a roll. In Storage, vol. 10. pp. 8; 2011:8.” .
[71] “Castillo MA, Rocha AS: Implementación de un sistema de VoIP de alta disponibilidad basado
en Asterisk y Heartbeat. Escuela Superior Politécnica del Litoral, Facultad de Ingeniería en Electricidad
y Computación; 2011.” .
[72] “CESGA: Instalación y evaluación de OpenNebula. CESGA; 2010.” .
[73] “Chu PB, Riedel E: Green Storage II: metrics and measurement.: Storage Networking Industry
Association . 2008.” .
[74] “Cisco, Intel: Converging SAN and LAN Infrastructure with Fibre Channel over Ethernet for
Efficient, Cost-Effective Data Centers. Cisco, Intel Corp.; 2008.” .
[75] “Cisco.: Fibre Channel over Ethernet. (Cisco. ed.: Cisco; 2010.” .
[76] “Bradley K, Lei J, Blackall C: Hacia un Sistema de Almacenamiento y Preservación en Código

Abierto. 2007.” .
[77] Dr. Brent Welch, “Object Storage Technology,” presented at the SNIA Education, 2014.
[78] SNIA, “Object Storage Understanding the What, How and Why behind Object Storage
Technologies,” presented at the SNIA Ethernet Storage Forum, 2014.
[79] “Critical Capabilities for Object Storage.” [Online]. Available:

https://www.gartner.com/doc/2664817/critical-capabilities-object-storage. [Accessed: 23-May-
2017].
[80] “Almacenamiento de bloques - Glosario de EMC.” [Online]. Available:

https://mexico.emc.com/corporate/glossary/block-storage.htm. [Accessed: 22-May-2017].
[81] G. Kovacs, “In the Cloud: Block Storage vs. Object Storage.” [Online]. Available:
https://cloud.netapp.com/blog/block-storage-vs-object-storage-cloud. [Accessed: 23-May-2017].
[82] “Benefits of NAS in the SMB - SureTech.com - IT Solutions for your WorkFlow,” 17-May-2017.
[Online]. Available: http://www.suretech.com/12320/Benefits_of_NAS_in_the_SMB. [Accessed: 17-
May-2017].
[83] Vmware, “Oracle Database 12c on VMware Virtual SAN 6.2 All-Flash.”
[84] “Planning for Database Availability,” 17-May-2017. [Online]. Available:

https://msdn.microsoft.com/en-us/library/ee290730(v=bts.10).aspx. [Accessed: 17-May-2017].
[85] “PostgreSQL: Documentation: 9.2: Creating a Database Cluster,” 17-May-2017. [Online].

Available: https://www.postgresql.org/docs/9.2/static/creating-cluster.html. [Accessed: 17-May-
2017].
[86] “Lustre* Software Release 2.x.” [Online]. Available:

http://doc.lustre.org/lustre_manual.xhtml. [Accessed: 02-May-2017].
101
[87] “How to Choose Network-Attached Storage for Your Business | PCWorld,” 17-May-2017.
[Online]. Available:
http://www.pcworld.com/article/209679/NAS_small_business_network_attached_storage_for_every
one.html. [Accessed: 17-May-2017].
[88] J. Tate, P. Beck, H. H. Ibarra, S. Kumaravel, L. Miklas, and others, Introduction to storage area
networks. IBM Redbooks, 2016.
[89] C. Poelker and A. Nikitin, Storage area networks for dummies, 2nd edition. Hoboken, NJ:
Wiley Publishing, Inc, 2008.
[90] “Part 4: Using NAS for Exchange Server storage,” SearchExchange, 17-May-2017. [Online].
Available: http://searchexchange.techtarget.com/tutorial/Part-4-Using-NAS-for-Exchange-Server-
storage. [Accessed: 17-May-2017].
[91] “Using Network Attached Storage (NAS) - MailStore Server Help,” 17-May-2017. [Online].
Available: https://help.mailstore.com/en/server/Using_Network_Attached_Storage_(NAS).
[92] “Clustered NAS vs traditional NAS solutions,” ComputerWeekly, 17-May-2017. [Online].

Available: http://www.computerweekly.com/feature/Clustered-NAS-vs-traditional-NAS-solutions.
[93] “Using a storage area network with virtual machines,” 17-May-2017. [Online]. Available:
https://technet.microsoft.com/en-us/library/cc708298(v=ws.10).aspx. [Accessed: 17-May-2017].
[94] “IBM Knowledge Center - Backup NAS,” 17-May-2017. [Online]. Available:

https://www.ibm.com/support/knowledgecenter/en/SSGSG7_6.4.0/com.ibm.itsm.client.doc/r_cmd_
bkupnas.html. [Accessed: 17-May-2017].
[95] Mark Lippit and Erik Smith, Networked Storage. Concepts and Protocols, vol. EMC Corp. 2014.
[96] “Redes convergentes.” [Online]. Available: https://access.redhat.com/documentation/es-

ES/Red_Hat_Enterprise_Linux/6/html/Performance_Tuning_Guide/distributed-systems-fcoe.html.
[97] “Converged Networks,” 2017. [Online]. Available:

http://www.brocade.com/content/html/en/deployment-guide/brocade-vcs-storage-dp/GUID-
9D96F5B6-D8E1-4033-BC91-F1561694BD87.html. [Accessed: 19-May-2017].
[98] M. Carlson et al., “Software defined storage,” Storage Netw. Ind. Assoc Work. Draft Apr, 2014.
[99] “ISO/IEC 24775:2011 - Information technology -- Storage management.” [Online]. Available:

https://www.iso.org/standard/55234.html. [Accessed: 24-May-2017].
[100] “Storage Management Initiative Specification (SMI-S) Releases | SNIA.” [Online]. Available:
https://www.snia.org/tech_activities/standards/curr_standards/smi. [Accessed: 24-May-2017].
[101] W.-P. Chen and C.-M. Liu, “Performance Comparison on the Heterogeneous File System in
Cloud Storage Systems,” 2016, pp. 694–701.
[102] B. Depardon, G. Le Mahec, and C. Séguin, “Analysis of six distributed file systems,” 2013.
[103] Dharavath Ramesh and Member IEEE, Neeraj PatidarOberoi, “Evolution and Analysis of
Distributed File Systems in Cloud Storage: Analytical Survey,” Int. Conf. Comput. Commun. Autom., pp.
1170–1173, 2016.
[104] M. Vaidya and S. Deshpande, “Critical Study of Performance Parameters on Distributed File
Systems Using MapReduce,” Procedia Comput. Sci., vol. 78, pp. 224–232, 2016.
[105] X. Zhang, S. Gaddam, and A. T. Chronopoulos, “Ceph Distributed File System Benchmarks on
an Openstack Cloud,” 2015, pp. 113–120.
[106] “Frank C. Casmartiño Bondarenko, Asiel Lara Brito, Lilia Rosa García Perellada,‘Comparación
de sistemas de ficheros distribuidos’ in 17 Convención Científica de Ingeniería y Arquitectura., Palacio
de Convenciones de La Habana, 2014.” .
102
[107] “Ceph Over Fibre for VMWare,” Ceph, 24-Dec-2012. [Online]. Available:
http://ceph.com/geen-categorie/ceph-over-fibre-for-vmware/. [Accessed: 29-May-2017].
[108] “Open Cloud Storage Setup — OpenNebula 5.2.1 documentation.” [Online]. Available:
https://docs.opennebula.org/5.2/deployment/open_cloud_storage_setup/index.html. [Accessed: 26-
May-2017].
[109] “OpenStack Docs: Storage concepts.” [Online]. Available: https://docs.openstack.org/arch-

design/design-storage/design-storage-concepts.html. [Accessed: 26-May-2017].
[110] “Red Hat Gluster Storage: Compatible Physical, Virtual Server and Client OS Platforms - Red
Hat Customer Portal.” [Online]. Available: https://access.redhat.com/articles/66206. [Accessed: 26-
May-2017].
[111] “Setting up Red Hat Gluster Storage in Microsoft Azure.” [Online]. Available:
https://access.redhat.com/documentation/en-
US/Red_Hat_Storage/3.1/html/Deployment_Guide_for_Public_Cloud/chap-Documentation-
Deployment_Guide_for_Public_Cloud-Azure-Setting_up_RHGS_Azure.html. [Accessed: 29-May-
2017].
[112] “Storage - Proxmox VE.” [Online]. Available: https://pve.proxmox.com/wiki/Storage.

[113] “Working with Storage — Apache CloudStack Administration Documentation 4.8.0

documentation.” [Online]. Available: http://docs.cloudstack.apache.org/projects/cloudstack-
administration/en/4.8/storage.html. [Accessed: 26-May-2017].
[114] Dan Braden, “Monitoring Measuring Bandwidth And Tuning SAN Storage From AIX2.,” 2014.
[115] S. D. Lowe, vExpert, M. V. P. Hyper-V, MCSE, and S. Editor, “Latency: The King of Storage
Performance Metrics,” Enterprise Storage Guide - News, Analysis & Reviews, 17-Mar-2016. [Online].
Available: http://www.enterprisestorageguide.com/latency-king-storage-performance-metrics.
[116] “PerfGuide: Analyzing Poor Disk Response Times.” [Online]. Available:

https://social.technet.microsoft.com/wiki/contents/articles/1516.perfguide-analyzing-poor-disk-
response-times.aspx. [Accessed: 08-May-2017].
[117] “VMware vSphere 5.1 Documentation Center. Disk parameters.” [Online]. Available:
https://pubs.vmware.com/vsphere-51/topic/com.vmware.vsphere.monitoring.doc/GUID-308BEF5A-
4B18-469D-9234-C4AD5CBCA593.html. [Accessed: 08-May-2017].
[118] F. A. P. García, A. S. González, L. R. G. Perellada, and A. A. G. Hernández, “Métricas y pruebas

de validación para sistemas de almacenamiento.,” Rev. Telem Tica, vol. 14, no. 1, pp. 24–38, 2015.
[119] “P. M. Timothy Grance, ‘The NIST Definition of Cloud Computing,’ 2011.” .
[120] “Focus Group on Cloud Computing, ‘FG Cloud Technical Report Part 1- Introduction to the
cloud ecosystem: definitions, taxonomies, use cases and high- level requirements,’ 2012.” .
[121] “Focus Group on Cloud Computing, ‘FG Cloud Technical Report Part 5: Cloud security,’ 2012.”
.
[122] “Focus Group on Cloud Computing, ‘FG Cloud Technical Report Part 4: Cloud Resource
Management Gap Analysis,’ 2012.” .
[123] “Solid State Storage (SSS) Performance Test Specification (PTS) | SNIA.” [Online]. Available:
https://www.snia.org/tech_activities/standards/curr_standards/pts. [Accessed: 10-Apr-2017].
[124] “Standards and Technology | DMTF.” [Online]. Available: https://www.dmtf.org/standards.

[Accessed: 10-Apr-2017].
[125] S. Ostermann, A. Iosup, N. Yigitbasi, R. Prodan, T. Fahringer, and D. Epema, “A Performance

Analysis of EC2 Cloud Computing Services for Scientific Computing,” in Cloud Computing, 2015, pp.
115–131.
103
[126] “Descripción de las pruebas de validación de clúster: almacenamiento.” [Online]. Available:

https://technet.microsoft.com/es-es/library/cc771259(v=ws.11).aspx. [Accessed: 07-Apr-2017].
[127] “Focus Group on Cloud Computing, ‘FG Cloud Technical Report Part 3: Requirements and
framework architecture of cloud infrastructure,’ 2012.” .
[128] Herb Tanzer and Chuck Paridon, “Energy Efficiency Metrics for Storage,” Santa Clara, 2014.
[129] Leah Schoeb, Vice Chair, SNIA Technical Council, “Enterprise Storage – Storage Efficiency,”
2014.
[130] “Features | ownCloud.org.” [Online]. Available: https://owncloud.org/features/. [Accessed:

19-May-2017].
[131] “Seafile - Open Source File Sync and Share Software.” [Online]. Available:
https://www.seafile.com/en/features/. [Accessed: 19-May-2017].
[132] “Pydio Features,” Pydio, 22-Sep-2016. [Online]. Available: https://pydio.com/en/features.

[133] W. C. Preston, Backup & Recovery: Inexpensive Backup Solutions for Open Systems. O’Reilly
Media, Inc., 2014.
[134] “Data-Recovery Customers.” [Online]. Available:

https://www.baculasystems.com/customers/success-stories. [Accessed: 26-May-2017].
[135] “Hadoop – Apache Hadoop 3.0.0-alpha2.” [Online]. Available:

http://hadoop.apache.org/docs/current/. [Accessed: 02-May-2017].
[136] “Home - iRODS Docs.” [Online]. Available: https://docs.irods.org/4.2.0/. [Accessed: 02-May-

2017].
[137] Hewlett-Packard, “Software-defined storage. What it is, how it works, and why you need it.”
2013.
[138] “Software Defined Storage. The New Software Platform,” 2017.
[139] M. Carlson et al., “Software defined storage,” Storage Netw. Ind. Assoc Work. Draft Apr, 2014.
[140] Mark Peters, Senior Analyst; and Monya Keane, Research Analyst, “Key Reasons to Use
Software-defined Storage—and How to Get Started,” 2015.
[141] E. Thereska et al., “IOFlow: a software-defined storage architecture,” 2013, pp. 182–196.
[142] “Data backup software features from Bacula Systems.” [Online]. Available:
https://www.baculasystems.com/products/bacula-enterprise/features. [Accessed: 26-May-2017].
[143] “Amanda Enterprise 3.1 Pre-installation Checks - Zmanda Documentation Wiki.” [Online].
Available: http://docs.zmanda.com/Template:Amanda_Enterprise_3.1_Pre-installation_Checks.
104
Anexos
ANEXOS
Anexo A. Comparativa de los métodos de diseños de sistemas de almacenamiento para centros
de datos
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]
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]
105
Anexos
Número
1 1 1 1 1 1 1 1 1 1 2
1 2 3 4 5 6 7 8 9
0 1 2 3 4 5 6 7 8 9 0
Aspectos
Estudio de la
misión,
visión, la
estructura
organizacion x x x
al de la
entidad
cliente y sus
característica
s.
Definición de
x x x x
los objetivos
del negocio.
F Caracterizaci
ón del
A estado inicial
x x x x x x
del sistema
S (infraestruct
ura y
E
servicios).
1 Definición de X X X X X X X X X X X X X X X
restricciones.
Definición de
los servicios
y/o
aplicaciones
X X X X
que
utilizarán el
SA, y su
caracterizaci
ón.
Definición de
los RNF a X x X X X X X X
soportar por
el SA.
DIVISIÓN DE X X X X X X X X X X X
FASES
F Estudio del
tipo de SA a X X X X X X X
A utilizar según
los RNF.
106
Anexos
S Identificación
de las
E características
de los discos a
2 emplear, así X X X X X X X X X X X
como las
controladoras
a utilizar
según los RNF
a cumplir.
Dimensionami
ento del SA
teniendo en
cuenta las
características X X X
de los
servicios y
aplicaciones
que se
demanden.
Identificación
de las
características
de las
tecnologías de X X X X X X X X X X X X X X X X
interconexión
de red, así
como los
dispositivos a
utilizar.
DIVISIÓN DE x x X
FASES
Selección de la
solución
(SAN/NAS) del
SA que se
acople a las
X X
características
de la empresa
F
según los RNF
A a cumplir.
Elección del
S software
correspondien X X X X X X X X X
E te a una
solución u
3 otra.
Propuesta
para la
selección del
Hardware del
SA.
Selección de X X X
los tipos de
107
Anexos
discos a
utilizar en el
sistema de
almacenamien
to según los
RNF.
Selección de
las tecnologías
de
interconexión X X X X X X X
de red que
respondan al
diseño de SA
escogido.
DIVISIÓN DE X X X X X X X X X X X X
FASES
Despliegue
de un
prototipo del
diseño
propuesto, o
su
modelación,
con las
configuracio
nes, X X X X X X X X X X X X X X X X X
aplicaciones
y
requerimient
F os del
mismo, para
A comprender
el
S comportamie
nto de la
E
propuesta.
4 Identificar las
herramientas
necesarias X X X X X X
para las
pruebas al
SA.
Identificar las
métricas
para conocer
X X X X X X X
si el sistema
responde de
manera
eficiente.
Ejecución de X X X X X X X X X X
las distintas
108
Anexos
pruebas al
SA.
Optimización X X X X X X X X X X
.
109
Anexos
Anexo B. Modelo de Referencia de la Nube Privada.
110
Anexos
Anexo C. Conceptos básicos de los sistemas de ficheros distribuidos. [40]
1- Estructura
Los sistemas de ficheros distribuidos están conformados por tres elementos fundamentales:
los servicios de archivos y de nombres, y los clientes. El servicio de archivos es el encargado de
mantener el contenido de los datos y sus atributos: tiempos de creación, último acceso, última
modificación, longitud y otros. Posee todas las especificaciones sobre la información que brinda
el sistema de archivos a los clientes. El servicio de nombres se encarga de proporcionar
transparencia e independencia en la ubicación para la ejecución de movimientos de la
información sin que haya variación en los nombres que se muestran a los clientes y sin el
conocimiento de los usuarios, teniendo como fines garantizar un mejor rendimiento y tolerancia
a fallas. Es donde se crean, se modifican y se buscan las entradas al sistema. Se encarga de
mapear los nombres de los archivos a objetos (ficheros, directorios). La interfaz del servicio de
nombres ofrece al cliente operaciones de buscar, añadir y borrar nombre. Algunos atributos del
fichero se mantienen por el servicio de nombres: tipo de dato, identificador del usuario,
propietario del dato, derechos de acceso y otros.
Los clientes acceden mediante una aplicación local a una interfaz del sistema de ficheros,
interpreta las llamadas locales que se realizan y generan las peticiones para los accesos
remotos. Tiene conocimientos sobre la ubicación de los servicios de nombres y de archivos,
y en algunos sistemas gestionan la información de la caché que se encuentra almacenada
localmente.
2- Arquitectura
Las arquitecturas de los sistemas de ficheros distribuidos son variadas, y en relación a la que
posean estarán determinadas muchas de sus bondades operacionales y funcionales, como la
capacidad de escalar y la de procesar eficientemente las solicitudes de los usuarios. Pueden
clasificarse como cliente-servidor, donde cada una de las partes tiene bien definidas sus
funciones, y punto a punto, donde ambas partes pueden asumir cualquiera de las funciones,
tanto cliente como servidor. Los servidores se encargan de los servicios de archivos y de
nombres, de garantizar la consistencia, la replicación y las copias de seguridad de la información,
y además de la autenticación y de la ejecución de las solicitudes de los clientes.
Los servicios de archivos y nombres pueden encontrarse en un mismo servidor o distribuidos a

través de varios, de forma conjunta o separada. La simetría que poseen los sistemas de ficheros
distribuidos para el manejo de los metadatos, o sea el servicio de nombres, así como el grado
de centralización que poseen estas simetrías, también permiten clasificar sus arquitecturas. En
111
Anexos
la Figura se muestran las clasificaciones acordes a cada uno de los elementos citados
anteriormente.
Los sistemas de ficheros asimétricos retienen el control del clúster en uno o unos pocos nodos.
Estos sistemas pueden ser globalmente centralizados al manejarse los datos vitales en un solo
nodo o localmente centralizados donde existe más de un nodo con dicha información, el nivel
de centralización influye considerablemente en la tolerancia a fallas y en la fiabilidad del
sistema. Los sistemas globalmente centralizados tienen un único punto de fallo, en muchos
casos adolecen de problemas de congestión de la información, disparan los tiempos de
respuesta incluso sobrepasando los umbrales fijados, y poseen grandes problemas de
escalabilidad y de fiabilidad. Los sistemas localmente centralizados garantizan mayor fiabilidad
y atenúan notablemente los problemas de escalabilidad con respecto a sus predecesores,
aunque no todos logran esto en las dimensiones necesarias. Los sistemas de ficheros simétricos
contienen en cada uno de los nodos los datos necesarios para comprender la estructura de la
información del sistema. Esto hace que sean sistemas descentralizados que proveen de alto
rendimiento, fiabilidad, tolerancia a fallas y de multiescalabilidad a los DFS.
3- Nombrado
El nombrado se ocupa de mapear los objetos lógicos a ubicaciones físicas. Los mecanismos de
nombrado forman parte del servicio de nombres, y tienen que brindar independencia y
transparencia en la ubicación para permitir el desarrollo de potencialidades en el sistema. Los
nombres de los archivos, en los DFS que proveen independencia en la ubicación, no varían al
cambiar su ubicación física permitiendo el movimiento de réplicas a nodos más cercanos a los
clientes, el balanceo de carga y otros. El establecimiento de abstracciones de nombrado que
112
Anexos
permitan que los clientes no tengan conocimientos de los detalles relacionados con el
almacenamiento real de la información, garantizan un mejor rendimiento, escalabilidad y
tolerancia a fallas. El nombrado en estos sistemas sigue alguno de los siguientes esquemas:
El nombrado de archivos mediante combinación del nombre del nodo remoto y del local
garantiza un amplio sistema de nombres y una simple resolución, pero provoca conflictos con
las transparencias de ubicación, migración y concurrencia del sistema, así como con la
independencia en la ubicación.
Los directorios remotos son adjuntos a los locales, dando la idea de un árbol de directorios
coherente. Puede ser accedido de forma transparente solo una vez que es montado
previamente y requiere que sea conocida la ubicación del servidor que hospeda el directorio
remoto. Causa problemas relacionados con la transparencia de ubicación.
La integración total de los componentes del sistema de ficheros brinda una estructura de
nombres global donde todos los ficheros pertenecen a un único espacio de nombres. Poseer un
único espacio de nombres comúnmente está relacionado con el empleo un solo nodo para su
gestión provocando bajo rendimiento y flexibilidad, y la incapacidad del sistema de tolerar las
fallas del servicio de nombres. La utilización en los DFS de este esquema de nombrado, hace
necesaria la implementación de varias facilidades de cómputo que cooperen entre ellas para
brindar tolerancia a fallas.
Los DFS realizan el nombrado mediante un mapeo directo entre los nombres y las direcciones,
o entre varios niveles, mediante el uso de identificadores. El mapeo de los nombres empleando
enlaces simbólicos asigna a cada nombre una dirección. La utilización de múltiples enlaces
simbólicos para mapear un único nombre de archivo es denominada enlace fuerte. Existen tres
categorías generales de nombrado:
Nombrado jerárquico: Está basado en el concepto de espacio de nombres, donde cada nombre
posee una dirección, se despliega en forma de jerarquía, y emplea nombres relativos y
absolutos. Cada uno de los nodos almacena los enlaces a sus semejantes.
Nombrado flotante: Inunda la red, preguntando por el nombre en cuestión, hasta que el nodo
correcto responde. Es muy útil para realizar el nombrado de forma homogénea y es muy común
su uso en los sistemas centralizados. Nombrado basado en atributos: Emplea para el nombrado
atributos distintivos de la información que permiten su identificación dentro del sistema.
4- Semánticas de acceso
Las semánticas son implementadas en los DFS para gestionar el acceso a los archivos
compartidos. Estos sistemas buscan proporcionar una semántica lo más cercana posible a la
que ofrecen los sistemas de ficheros tradicionales, pero el hecho de encontrarse distribuidos
provoca una fuerte penalización en su rendimiento. Los DFS, en dependencia de su finalidad,
113
Anexos
utilizan uno u otro tipo de semántica para garantizar una relación razonable entre esta y la
eficiencia del sistema, por lo que en muchas ocasiones no la cumplen íntegramente. El
desempeño de los clientes, el tráfico en la red y la carga de los servidores conforman la eficiencia
del sistema, y aunque los tres son importantes, siempre son afectados en alguna medida para
garantizar los objetivos de diseño. Las semánticas se pueden clasificar en varios tipos:
Semántica secuencial: Las operaciones sobre un fichero se ordenan de forma secuencial en el
tiempo. Una lectura devuelve la última actualización realizada al fichero mediante una escritura.
Es fácil de implementar en los sistemas que poseen un único servidor y no emplean la caché de
los clientes. Puede emplearse la política de escritura simultánea para la actualización de la
caché, realizando notificaciones a los clientes que poseen copias de los archivos aunque mejora
el rendimiento requiere de estados extras que generan mayor tráfico en la red.
Semántica de sesión: Las sesiones comienzan al abrir un fichero y finalizan cuando se cierra. Los
ficheros son obtenidos y manipulados en una copia local que se carga al abrirlo, y luego se
actualiza al finalizar sesión. Los cambios en un archivo abierto son visibles únicamente en el
nodo que los modificó y solo una vez cerrado se hacen visibles a futuras sesiones. Provoca que
varios nodos puedan poseer diferentes imágenes del mismo archivo y que dos sesiones abiertas
sobre un mismo fichero puedan terminar de forma concurrente, manteniéndose en el sistema
solo las modificaciones de la última sesión. La modificación por parte de los clientes de datos
que se encuentren compartidos solo se propaga una vez cerrada la sesión. Este tipo de
semánticas no es adecuado para procesos que acceden de forma concurrente a los ficheros.
Ficheros inmutables: Los ficheros no pueden ser modificados, solo creados o leídos, o sea que
son compartidos para sólo lectura. La modificación de los datos se realiza creando un nuevo
fichero que conserva el nombre del anterior. La semántica de ficheros inmutables es de ayuda
para la replicación aunque no garantiza que sean actualizadas las copias de los archivos
obsoletos.
Semántica de transacciones: El acceso a los ficheros se produce de forma atómica, o sea que se
ejecuta desde el inicio y hasta el fin de una operación. Todas las transacciones tienen que ser
completadas, si una parte no es satisfactoria la transacción es invalidada. La ejecución de forma
atómica debe estar garantizada en todas las circunstancias incluyendo caídas, errores y fallas
de energía. El sistema debe asegurar que dos transacciones ejecutadas de forma concurrente
sean tratadas de forma similar a una ejecución secuencial.
5- Caching
El caching se encarga de mantener los archivos recientemente usados, accesibles de forma
eficiente, garantizando un mejor rendimiento al almacenar información. Es empleado para
reducir las I/O a disco y para disminuir el tráfico en la red. La caché se mantiene siempre en la
memoria principal del servidor con tamaños de bloques que pueden ser variables, llegando a
abarcar archivos completos. En los DFS el proceso de caching puede realizarse tanto en el cliente
como en el servidor, alojado en la memoria principal o en disco como se tratan a continuación:
114
Anexos
Servidor: El rendimiento mejora considerablemente haciendo caching de los archivos

recientemente usados en la memoria principal del servidor. Permite que los clientes que
accedan a información reciente lo hagan directamente a la memoria sin que se tengan que
realizar I/O al disco. El servidor usa solo caching en la memoria principal.
Cliente: El caching en disco hace que la información esté disponible incluso en caso de fallas en
el ordenador, pero aún así las velocidades son inferiores y conlleva que tengan que utilizarse
tanto el disco como la memoria principal.
El caching en memoria principal tanto de cliente como servidor permite implementar

mecanismos simples de validación de la consistencia de la información. Los DFS comúnmente
emplean el caching para brindar mayor rendimiento, y de conjunto con este, mecanismos como
bloqueos o leases para garantizar la consistencia de los archivos compartidos que poseen los
clientes.
Las políticas de actualización de las escrituras en caché permiten guardar los cambios realizados
localmente por los clientes en los nodos del DFS. Estas políticas repercuten considerablemente
en el rendimiento y la fiabilidad de estos sistemas.
Escritura simultánea: Las operaciones de escritura son inmediatamente transferidas a los
servidores, o sea que la caché es empleada solo para las operaciones de lectura, constituye la
estrategia más simple y de mayor fiabilidad.
Escrituras demoradas: Las modificaciones de los archivos son escritas en la caché y
posteriormente son realizadas hacia el servidor. Las operaciones de escrituras se ejecutan
rápidamente y si la información es sobrescrita antes de ser enviada al servidor, solo la última
actualización es escrita al servidor.
Escritura final: La caché local es empleada todo el tiempo que los archivos están abiertos, y una
vez cerrados, los datos son escritos al servidor. En el caso de archivos que estén abiertos por
largos períodos de tiempo esta política garantiza mejor rendimiento que las escrituras
demoradas, pero provoca problemas de consistencia.
6- Tipos de servicios
Los modelos de servicios de archivos para el acceso a la información que brindan los sistemas
de ficheros distribuidos permiten seleccionar un sistema u otro en relación a las necesidades
concretas de diseño. Los DFS presentan tres modelos de operación:
Carga/descarga: Es un modelo simple que emplean dos operaciones fundamentales

lectura/escritura. Mediante la lectura son transferidos los archivos completos desde el servidor
hasta el cliente que realiza la solicitud y almacenados localmente, y con la escritura son copiados
los archivos que posee el cliente de vuelta al servidor.
115
Anexos
Acceso remoto: El empleo de este modelo permite que se puedan realizar sobre el servicio de
archivos operaciones remotas para abrir, cerrar, leer, escribir, obtener atributos y otras sobre
los ficheros. El sistema de ficheros se encuentra verdaderamente en funcionamiento desde los
servidores.
Híbrido: Este modelo combina las características de los dos tratados anteriormente y en algunos
casos emplea el caching en los clientes. Permite lograr un mayor rendimiento al usar
mecanismos para garantizar la consistencia de la información y de la caché en los casos
necesarios.
La carga/descarga no es eficiente para el trabajo con pequeños archivos por las frecuentes
solicitudes que tienen que ser realizadas, trae problemas para los clientes que no tienen
suficiente espacio en la caché para almacenar el archivo completo y provocaría problemas de
consistencia ante múltiples solicitudes. Es empleado normalmente en sistemas que utilizan
semánticas de sesión. El acceso remoto conlleva a que los servidores sean accedidos
constantemente mientras se esté produciendo el acceso a los archivos a diferencia de la carga/
descarga. El modelo híbrido permite el uso de cualquiera de las semánticas y a la vez lograr
mejores índices de rendimiento y fiabilidad.
7- Tolerancia a fallas
El diseño adecuado de un DFS tiene que incluir técnicas que soporten la capacidad de tolerar
fallas de hardware y de software. La tolerancia a fallas permite que los sistemas continúen en
funcionamiento, en algunos casos puede que reduzcan en alguna medida su potencia, en vez
de que fallen completamente cuando algunos componentes estén fuera de servicio. Los
sistemas ideales no deben presentar fallas que causen su caída y afecten su fiabilidad, y aunque
es imposible de lograr, en la práctica se emplean técnicas que se aproximan. La habilidad de los
DFS de tolerar fallas se expresa a través de la fiabilidad y la disponibilidad que ofrecen. El
principio básico para un diseño tolerante a fallas se basa en brindar redundancia de los
componentes de hardware, de la estructura de datos y de los recursos de cómputo. La
redundancia provoca costos monetarios y de tiempo, y para poder garantizar una buena
relación costo/beneficio tiene que existir equivalencia entre el nivel de tolerancia a fallas
deseado y la eficiencia del sistema. La redundancia de los recursos de cómputo requiere que las
capacidades de procesamiento en uso por el sistema, al ocurrir una falla, sean reasumidas y a
diferencia de la redundancia de hardware, las recuperaciones ante fallas son muy lentas. La
redundancia de hardware por otra parte incrementa los costos de hardware, por lo que en
muchos casos para el diseño de un sistema tolerante a fallas son implementadas técnicas
híbridas que combinan varios tipos de redundancia tanto de hardware como de software. La
redundancia de la estructura de datos es abordada en el próximo apartado por su importancia
116
Anexos
para el rendimiento y la disponibilidad del sistema, así como la persistencia de la información

ante fallas. Algunas de las técnicas más usadas son tratadas a continuación.
Redundancia modular y versiones de grupos: Utiliza varias réplicas idénticas de módulos de
hardware y un mecanismo de consenso que compara las salidas de cada uno de los módulos y
determina la que se debe usar por criterios de mayorías u otros. Las versiones de grupos basan
su funcionamiento en las versiones que aportan diferentes módulos de software. Emplea
también un mecanismo de consenso para el manejo de las versiones y determinar la salida que
debe ser aplicada. Las versiones son ofrecidas por diferentes grupos donde cada uno espera
que los otros no posean salidas con sus mismos problemas para poder dar una salida correcta.
Tolera fallas de hardware y de software. Ambas técnicas emplean algoritmos de consenso
distribuidos para la toma de decisiones respecto a las fallas que ocurren en los DFS.
Puntos de chequeo y estados anteriores: Los puntos de chequeo guardan la información de
estado del sistema y permiten que pueda ser puesto en funcionamiento con el estado que se
encuentra guardado. El dispositivo donde se almacenan los estados es tolerante a numerosas
fallas del sistema, como cortes de la energía eléctrica y otras que se encuentran fuera de su
naturaleza, para garantizar tolerancia en caso de fallas propias se emplea la redundancia de la
estructura de datos. Los registros de eventos, el journal, y las técnicas de actualizaciones de
software son empleadas para la verificación y comprobación del estado del sistema, y de la
consistencia de la información ante la ocurrencia de fallas.
Los tipos de servidores de información determinan la capacidad del servicio de archivos de

tolerar fallas relacionadas con los datos que están siendo accedidos por los clientes. Pueden
diferenciarse dos categorías de servidores que determinan las características del servicio de
archivos:
Servidor sin estado: En las operaciones sobre archivos estos servidores no almacenan
información acerca del cliente. El cliente suministra en cada llamada toda la información
necesaria para realizar la operación en cuestión. Esta categoría tiene las ventajas de que las
fallas no causen daños en el servidor, y de que como no se guardan los datos de estados, el
servicio puede ser iniciado fácilmente ante cualquier eventualidad.
Servidor con estado: Estos servidores almacenan la información de las solicitudes de los clientes,
llevan la relación de los archivos que son abiertos y liberan la memoria cuando se desconectan
o dejan de funcionar alguno de los clientes. La primera solicitud que hacen los clientes requiere
mayor información, en las sucesivas solo se utilizan los campos específicos de dicha operación.
Aporta mejor rendimiento al sistema al no tener que suministrarse todos los campos
constantemente, pero es nocivo para la fiabilidad por las pérdidas que se producen en los
servidores ante caídas del sistema.
117
Anexos
8- Redundancia y sincronización de la estructura de datos

La redundancia de la información es garantizada en los DFS mediante el empleo de software
basado en las tecnologías RAID2 (RAID 0, RAID 10) y a través de la replicación para proveer
tolerancia a fallas. Los sistemas de ficheros distribuidos llevan a cabo la replicación a nivel de
servidor, de directorio o de archivo para tratar con fallas de procesamiento, de disco o de red.
La replicación de los datos en los sistemas de ficheros distribuidos es empleada para balancear
la carga y disminuir la latencia ofreciendo mejor rendimiento, disponibilidad y tolerancia a fallas.
La redundancia permite que estos sistemas operen de forma ininterrumpida, aunque existan
fallas parciales, al costo del mantenimiento de las réplicas de la información. La sincronización
es empleada para distribuir las actualizaciones realizadas en los archivos que se encuentran
replicados hacia todo el clúster. La estrategia de replicación basada en solicitudes de
actualización es empleada para la actualización de las réplicas de los archivos modificados por
los clientes. Los datos modificados localmente, una vez actualizados en el sistema, son
sincronizados para brindar consistencia a las réplicas que se encuentran distribuidas en los
nodos. Puede suceder que alguno de los otros nodos esté trabajando con la réplica que tienen
almacenada y no puedan realizar la modificación. En estos casos es donde juegan su papel los
mecanismos de consistencia, el caching y las políticas necesarias que permiten que cada cliente
tenga la última versión de los datos. Esta estrategia puede clasificarse en:
Sincrónica: Todas las réplicas son actualizadas antes de finalizar la operación. Permite la
detección de fallas y la coordinación (por ejemplo ping y leases) basadas en tiempo, para brindar
consistencia. Es empleada en sistemas que utilizan semánticas fuertes similares a los sistemas
de ficheros distribuidos tradicionales.
Asincrónica: La actualización se realiza a un conjunto de réplicas, el resto son realizadas
progresivamente. Puede provocar que el contenido de un mismo fichero no sea consistente
para dos usuarios diferentes, por ejemplo, si un usuario está actualizando el mismo archivo que
otro está copiando o porque no se encuentra dentro de las réplicas que fueron actualizadas. La
actualización de forma asincrónica no permite la detección de fallas ni la coordinación basada
en tiempo de los sistemas. Tiene la ventaja de emplear semánticas simples.
9- Consistencia
Las operaciones que son realizadas en los DFS tienen que producirse de forma consistente para
permitir que la información a la que acceden los clientes esté actualizada. La distribución, la
replicación y el soporte de accesos concurrentes constituyen los mayores retos en estos
sistemas para que exista consistencia. Un mismo archivo aunque se encuentre en diferentes
ubicaciones, por estar replicado o almacenado en la caché de algún cliente, tiene que poseer la
misma información en todas sus instancias. Los sistemas comúnmente para mantener la
consistencia de la información replicada actualizan una de las copias y luego propagan los
cambios a todos los nodos que la poseen, permite que todos los clientes obtengan el contenido
real de los archivos a los que acceden. Es necesario para el diseño de los DFS implementar
118
Anexos
mecanismos para lograr la consistencia de los archivos en la caché de los clientes por lo que se
emplean diferentes mecanismos para su actualización, así como también para garantizar la
consistencia de la información redundante que se encuentra distribuida. Los DFS utilizan
algunos de estos mecanismos y funcionalidades de acuerdo a las semánticas y tipos de servicios
de diseño buscando un equilibrio entre rendimiento y disponibilidad.
Los archivos que se encuentran distribuidos en los sistemas que utilizan replicación, y sus
copias, tienen que ser consistentes, por lo que es necesario usar mecanismos para evitar que
más de un cliente esté accediendo a un archivo que va a ser escrito:
Bloqueos en escrituras concurrentes sobre archivos compartidos: El acceso al sistema de
ficheros, de al menos un cliente para la escritura en archivos compartidos, hace que todas las
copias existentes sean bloqueadas para garantizar la consistencia de la información
almacenada.
Prohibición de caching en escrituras concurrentes: En escenarios donde varios clientes abren
un archivo y al menos uno de ellos realiza una escritura, el servidor informa a todos los clientes
que eliminen la copia del archivo que tienen en la caché.
Los DFS que emplean la caché de los clientes requieren de la implementación de mecanismos
para la verificación de la consistencia del contenido de la copia local del cliente con la que se
encuentra alojada en el sistema. Esto constituye un problema de gran complejidad al tener cada
cliente su propia caché, y dado el hecho de que son sistemas distribuidos, el número de usuarios
que pueden estar accediendo simultáneamente es elevado. Algunos de los mecanismos
empleados para dar consistencia a la información en caché son abordados a continuación:
Cliente iniciado: El cliente contacta con el servidor e inicia un chequeo de validez para
comprobar si la información que tiene en la caché es consistente con la copia alojada en el
servidor. La frecuencia de validación es uno de los problemas ya que si es realizada cada cortos
períodos la red y el servidor pueden sobrecargarse.
Servidor iniciado: El servidor registra los ficheros que tienen en la caché cada uno de los clientes.
Las inconsistencias pueden ocurrir cada vez que un archivo es modificado y se encuentra en la
caché de algún cliente. En todas las ocasiones que ocurren actualizaciones el servidor envía un
mensaje de invalidación a los clientes que poseen dicha información en caché. Los sistemas que
utilizan la semántica de sesión los mensajes de validación son necesarios solo cuando el archivo
es cerrado. En el caso de la semántica POSIX de los sistemas UNIX los mensajes de validación
son necesitados con mayor frecuencia.
10- Seguridad
La seguridad en los sistemas de ficheros distribuidos puede ser abordada en varios sentidos,
acorde a los objetivos de diseño de cada sistema. Una política de seguridad exhaustiva debe
119
Anexos
abarcar elementos como confidencialidad, integridad, disponibilidad y rendimiento. Los tres

primeros son elementos referidos comúnmente en el área de la seguridad de los sistemas
computacionales, pero además se hace necesario analizar el rendimiento del sistema para dar
el balance apropiado entre la seguridad y el consumo de recursos de procesamiento. Las
políticas de seguridad se enfocan en los siguientes aspectos:
Integridad: La integridad tiene que ser mantenida implementando mecanismos protectores que
eviten que se corrompan los datos ante accidentes y ataques dañinos. Los mensajes de
notificación pueden ser útiles en la comunicación con el servidor de metadatos y así garantizar
la integridad de la información. Es implementada ampliamente a través de la autenticación que
permite verificar la confiabilidad de la fuente de donde provienen los datos, y también con la
encriptación.
Confidencialidad: Los sistemas tienen que poseer funcionalidades de protección para que se
eviten los accesos no autorizados. Pueden emplearse técnicas de autorización como ACL y
Capability Lists que garantizan la confidencialidad de la información.
Disponibilidad: Es considerada de acuerdo al tiempo, el espacio y la representación, y aunque
estén ocurriendo fallas, el sistema debe mantenerse disponible a los usuarios autorizados en
períodos de tiempo aceptables sin monopolizar el espacio de almacenamiento disponible y a
través de una representación que pueda ser comprendida.
Rendimiento: Es necesaria una relación permisible entre el nivel de seguridad y el rendimiento
del sistema; las medidas de seguridad que son agregadas requieren mayores recursos de
procesamiento y provocan conflictos en dicha relación.
11- Autonomía
Los algoritmos y componentes que incluyen actualmente los DFS ofrecen mejoras
considerables en cuanto a disponibilidad, rendimiento y capacidad de recuperación, sin
embargo, provocan un incremento en la complejidad y en los conocimientos necesarios para su
gestión. Todo esto catapultó el surgimiento de nuevos diseños dotados de funcionalidades
autonómicas, a continuación, se tratan algunas de las capacidades de autogestión más
importantes:
Auto-configuración: Los sistemas autónomos son configurados mediante políticas de alto nivel
que ejecutan las acciones necesarias para lograr los objetivos definidos para su funcionamiento.
La autonomía radica en que el sistema tiene que traducir esas políticas de alto nivel en
configuraciones de bajo nivel, simplificando considerablemente el proceso de configuración del
sistema.
Auto-optimización: Constituye la búsqueda continua de formas de optimizar el funcionamiento
del sistema. Los elementos fundamentales son analizados continuamente en búsqueda de un
mejor rendimiento y utilización. El balance de la carga de procesamiento y la distribución de la
información que es frecuentemente accedida son algunos ejemplos de la optimización de los
sistemas de ficheros distribuidos.
120
Anexos
Auto-recuperación: En los sistemas distribuidos la recuperación de forma autónoma consiste

en un grupo de componentes que se encuentran disponibles en todo momento, incluso gran
parte del tiempo sin asumir su funcionalidad, para la recuperación ante fallas. La replicación es
usada para brindar redundancia y mayor disponibilidad, pero necesita mecanismos de
recuperación en caso de inconsistencias. El monitoreo de la estructura de la información
almacenada a través de reportes de estado y de distribución permite la toma de medidas en
caso de que no exista el número de réplicas definidas. Los movimientos internos en el clúster
por la caída de un servidor o disco en dependencia del nivel de replicación de cada uno
constituye otro de los ejemplos.
121
Anexos
Anexo D. Análisis de las soluciones SLCA más destacadas para SA.
a. Hadoop Distributed File System (HDFS) [135]
HDFS es un sistema de ficheros distribuido de acceso en paralelo, de SLCA, diseñado para

trabajar con hardware de propósito general e inspirado en el Sistema de Ficheros de Google
(GFS). Persigue brindar fiabilidad al tratar con grandes archivos y extensos clústeres de
computadoras. Está provisto de interfaces para el movimiento de las aplicaciones a donde se
encuentra la información, siguiendo el principio "mover la computación es más barato que
mover los datos". Este sistema trata la información a nivel de bloques, y permite configurar el
tamaño y el factor de replicación para cada uno. Los ficheros cumplen con write-once-read-
many, siendo escritos estrictamente solo una vez.
1.1 Arquitectura
Este sistema de ficheros posee una arquitectura asimétrica, globalmente centralizada. El

NameNode se ocupa del servicio de nombres del sistema. Utiliza un modelo máster/esclavo
para el manejo de los metadatos donde solo hay un NameNode activo, pero existe uno
secundario con el que se fusiona periódicamente y en caso de fallas toma el control del sistema.
Los DataNodes se encargan del servicio de datos y almacenan la información. Los datos son
distribuidos y replicados en los DataNodes que normalmente están asociados a cada uno de los
nodos del clúster y utilizan su almacenamiento local. Los ficheros son guardados en los
DataNodes en un grupo de bloques del mismo tamaño, excepto el último. Todos los nodos están
interconectados a través de protocolos sobre TCP/IP. La comunicación se realiza a través de
ClientProtocol y DataNodeProtocol, ambos protocolos emplean RPC. El NameNode responde a
los RPC que le hacen tanto los clientes como los DataNodes, pero nunca inicia uno.
NameNode
El NameNode se encarga del manejo del espacio de nombres del sistema y de regular el acceso
de los clientes a los archivos. Cualquier cambio en los metadatos de los archivos almacenados
es guardado por el NameNode. Periódicamente recibe los reportes de estado y de los bloques
de cada uno de los DataNodes del clúster. El reporte de estado brinda información acerca de la
capacidad de almacenamiento del DataNode, número de transferencias en progreso y otras.
El NameNode se encarga de todas las decisiones relacionadas con la replicación de los bloques.
El factor de replicación de cada uno de los archivos es llevado por el NameNode y puede ser
modificado en cualquier instante. Todos los metadatos son almacenados en el sistema de
ficheros local del NameNode y se mantienen en la memoria el espacio de nombres y el mapeo
de los bloques. Se emplean dos archivos para el manejo del espacio de nombres el Editlog y el
FsImage. En el Editlog se guardan todos los cambios que ocurren en los metadatos del sistema
como la creación de un fichero o el cambio del factor de replicación. El espacio de nombres, los
122
Anexos
permisos, las modificaciones, los tiempos de accesos y las cuotas de disco son representados a
través de los inodes. Los inodes y el mapeo de bloques a ficheros es almacenado en el FsImage.
DataNode
Los DataNodes son los responsables de completar las solicitudes de lectura y escritura de los
clientes. Se encargan de crear, eliminar y replicar los bloques de información bajo las
instrucciones del NameNode. Cada una de las réplicas de los bloques en los DataNode son
representadas por dos archivos en el sistema de ficheros local del nodo. Uno contiene los datos
como tal y el otro los metadatos del bloque incluyendo la suma de verificación de los datos de
ese bloque y la marca de cuando fue generado. Los DataNodes almacenan los los bloques como
archivos en su sistema de ficheros local aunque no tienen conocimientos en relación a los
archivos del HDFS.
1.2 Consistencia
Los clientes que buscan escribir alguna información son autorizados a través de un permiso que
les permite solo el acceso para esa escritura a fichero. HDFS implementa el modelo write-once-
read-many que presupone que cuando se va a realizar una escritura el fichero es creado,
guardado y cerrado sin que tenga que realizarse ninguna modificación posterior. No permite
acceso de escritura concurrente, aunque un archivo que se encuentre en proceso de escritura
puede ser leído. Emplea leases y bloqueos de la información que poseen los clientes que va a
ser modificada para lograr la consistencia de la caché. Los clientes comprueban la consistencia
de la información a la que accedieron a través de la suma de verificación que realizan de la copia
que obtienen, comparándola con la suma de verificación de cada uno de los bloques que fue
generada por el sistema de ficheros.
1.3 Redundancia y sincronización
HDFS divide los ficheros en una secuencia de bloques del mismo tamaño, excepto el último, y
son replicados en todo el clúster. La replicación se realiza siguiendo una política de ubicación
que busca garantizar tolerancia a fallas. La política por defecto es que en ningún DataNode
puede haber más de una copia, y en ningún rack, más de dos copias de un mismo bloque. La
política de ubicación de las réplicas está estrechamente vinculada con los niveles de
disponibilidad, con los índices de rendimiento y con el grado en que el sistema puede tolerar
las fallas. Para disminuir el uso de ancho de banda y la latencia en las lecturas, el sistema emplea
la réplica más cercana al origen de la solicitud del cliente. El NameNode utiliza los reportes
acerca de los bloques para verificar el número de réplicas de cada uno y rectificar su
distribución. En caso de que exista mayor número de réplicas el NameNode selecciona las que
serán eliminadas, tratando de no disminuir el número de racks en que se encuentran y
decantándose por los DataNodes que poseen la menor cantidad de espacio disponible en disco,
para poder brindar mayor rendimiento y tolerancia a fallas. Un menor número de réplicas
123
Anexos
conlleva a la planificación acorde a la política de ubicación establecida y al posicionamiento de

las réplicas pendientes en una cola de espera que es verificada periódicamente. La replicación
es realizada de modo asincrónico, aunque el sistema posee de herramientas para hacerlo de
modo sincrónico.
1.4 Tolerancia a fallas
HDFS tiene todos sus nodos completamente conectados y comunicados entre ellos, para poder
detectar fallas en la red o en los servidores y brindar fiabilidad. Cuando inicia el sistema cada
DataNode compara la versión del software y el ID del espacio de nombres que le fue asignado
con el NameNode. Si alguno de estos elementos no coinciden el DataNode se apaga para
preservar la integridad del sistema. Los DataNodes también realizan su registro con el
NameNode que consiste en hacerse reconocibles incluso aunque poseen otra dirección IP o
puerto. Una vez registrados, cada hora, los DataNodes envían el reporte acerca de los bloques,
y cada tres segundos, el de su estado. En caso de no ser recibido un reporte de estado, como
máximo diez minutos desde el último, el DataNodes es considerado fuera de servicio. Todo esto
le permite al NameNode estar al tanto del estado de los DataNodes y la toma de las decisiones
necesarias para evitar fallas en todo el sistema y para garantizar la disponibilidad de la
información almacenada.
1.5 Otras características y funcionalidades
HDFS es diseñado, más para el procesamiento de grandes lotes de datos, que para brindar una
interfaz interactiva para los usuarios. Permite el acceso bajo demanda de las aplicaciones a la
información almacenada. Parte del principio de que es más importante garantizar un alto
throughput en el acceso a los datos que lograr una baja latencia. Los sistemas con semánticas
POSIX imponen fuertes requerimientos que afectan este escenario por lo que un grupo de áreas
fundamentales fueron relajadas para incrementar el throughput. Este sistema no cumple con
las semánticas POSIX.
Este DFS posee un módulo de acceso basado en FUSE que le permite ofrecer mayor
compatibilidad. Este módulo brinda a los clientes un sistema de ficheros virtual a nivel de
usuarios con la estructura correspondiente a los directorios físicos remotos. Además, se encarga
de encausar todas las solicitudes de los clientes de forma remota, o sea que se ocupa de la
mediación entre cada una de las partes, empleando mecanismos que puedan ser comprendidos
por ambos.
1.6 Balanceo de carga
En este DFS son fijados umbrales en relación al ratio permisible por cada uno de los DataNodes
para el balanceo de la carga. El ratio de un nodo es definido como la relación entre el espacio
usado con respecto a la capacidad total. El clúster se encuentra balanceado si el uso de cada
DataNode difiere del uso del clúster en no más del valor de umbral. En los nodos que no están
124
Anexos
balanceados son almacenadas las réplicas que son movidas desde otros respetando las políticas
de ubicación establecidas.
1.7 Limitaciones
1. Centralización: El HDFS emplea un servidor de metadatos centralizado. En caso de fallas

en el NameNode el sistema no estará disponible debido a que se emplea el respaldo
existente en el secundario solo con el reinicio del NameNode por lo que no garantiza
que el sistema esté operativo ante fallas de esta índole.
2. Escalabilidad: El almacenamiento de todo el espacio de nombres y del mapeo de los
archivos a bloques en la memoria del NameNode ha conllevado a que se vea limitado el
número de ficheros y bloques que pueden ser agregados.
3. Gestión de usuarios y de autenticación: Hadoop DFS no posee mecanismos de seguridad
aunque por ser SLCA pueden emplearse aplicaciones de acuerdo a las necesidades que
se tengan. No tiene implementadas cuotas de usuario ni protección de acceso. No
soporta enlaces simbólicos ni fuertes.
b. Gluster File System (GlusterFS) [27]
Gluster es una tecnología de almacenamiento de SLCA diseñada para manejar volúmenes de

datos hospedados en diferentes servidores a través de un sistema de ficheros distribuido y
replicado en red. Cumple con la semántica de los sistemas POSIX y soporta almacenamiento de
objetos y basado en bloques. Busca facilitar el manejo de volúmenes y usuarios e incorpora
flexibilidad en la gestión de los datos de aplicaciones y de las imágenes de máquinas virtuales.
Constituye una plataforma NAS multiescalable, totalmente funcional, comúnmente empleada
en ambientes virtualizados y de Nubes. Posee un espacio de nombres global, donde los
metadatos se encuentran distribuidos sin el uso de servidores dedicados para ello.
Esta tecnología puede ser exportada como sistema de ficheros, GlusterFS, y a través de varios
protocolos a nivel de archivos como NFS, CIFS, FTP, WebDAV, HTTP y HTTPS. Ejecuta todas sus
funciones en el espacio de usuario para no comprometer el rendimiento del sistema. Emplea
un algoritmo hash elástico (EHA), para la ubicación de la información, que constituye elemento
clave de su funcionamiento. Permite el empleo de recursos de forma independiente, tanto de
rendimiento como de capacidad, desde el orden de los TB hasta el de los PB. Soporta la
utilización de hardware de propósito general y de infraestructuras públicas de almacenamiento
en la Nube.
GlusterFS puede ser configurado de acuerdo a las políticas de protección ante fallas que sean
necesarias para garantizar la redundancia de la información como RAID 5, RAID 6, una mezcla
de varios, replicación u otros. Brinda alto rendimiento y emplea un pool de gestión centralizado.
2.1 Arquitectura
125
Anexos
GlusterFS posee una arquitectura punto a punto, simétrica y descentralizada. Está conformado
por un clúster de ordenadores donde cada uno realiza la función tanto de cliente como de
servidor, y la información es distribuida y almacenada en sus sistemas de ficheros locales (ext4,
xfs, zfs y otros). GlusterFS básicamente es una capa sobre los sistemas de ficheros locales que
permite escalar el sistema al orden de los PB y es accesible a través de un único punto de
montaje. Además, no utiliza servidores de metadatos centralizados, como es común en los
sistemas tradicionales, aportándole multiescalabilidad y un rendimiento muy superior. Los
accesos de las API y los clientes son realizados empleando REST y un módulo de montaje FUSE.
Los servidores exportan el sistema de ficheros local como un volumen virtual, mientras los
clientes que acceden al clúster ejecutan los traductores que manejan la estructura de GlusterFS,
es por ello que cada nodo es tanto cliente como servidor. El espacio de nombres es global,
distribuido a través de todos los servidores, con los metadatos almacenados en el mismo
sistema de ficheros local, manejado a través del algoritmo EHA. GlusterFS utiliza este algoritmo
con las entradas del nombre del fichero y del directorio para generar una etiqueta hash asociada
a cada uno de los archivos, y luego guardarla junto al mismo fichero como su identificador
dentro del sistema.
Este sistema de ficheros puede ser escalado linealmente en rendimiento y capacidad como
resultado de la eliminación de los servidores de metadatos, la distribución efectiva de los datos
y el uso de paralelismo en los accesos. Además, no gestiona directamente el almacenamiento
de la información a nivel de discos/bloques, si no que lo maneja como un todo, y es por ello que
no necesita guardar los metadatos de forma independiente. El EHA genera identificadores
únicos, elimina los escenarios de riesgo, permite que el sistema tenga un buen rendimiento
debido a la descentralización de los metadatos, y asigna los archivos a volúmenes virtuales
aportando multiescalabilidad y fiabilidad al sistema. Los nodos de almacenamiento de GlusterFS
pueden ser interconectados empleando Infiniband RDMA o TCP/IP.
Servidor
En los servidores el almacenamiento es manejado a nivel de bloques y exportado como un

volumen virtual mediante el demonio glusterd. Las unidades elementales de almacenamiento
son llamadas bricks y un servidor puede estar formado por uno o varios. Los bricks almacenan
la información en el sistema de ficheros local de cada servidor a través de los traductores que
se ejecutan del lado de los clientes.
Cliente
Los clientes del sistema GlusterFS son los encargados de mantener la estructura del
almacenamiento al ejecutar de su lado los traductores. La mayor parte de la funcionalidades de
este sistema se implementan como traductores, a continuación se citan algunos.
4. Replicación de archivos.
126
Anexos
5. Balanceo de carga.
6. Fragmentación de archivos.
7. Tolerancia a fallas a nivel de bricks.
8. Operaciones I/O y almacenamiento en caché de disco.
9. Cuotas de almacenamiento
Los clientes se manejan entre unos y otros de forma independiente, y no se comunican

directamente entre sí. Los traductores conectan uno o varios subvolúmenes y se encargan de
administrar entre ellos la consistencia de los datos.
En GlusterFS los volúmenes pueden estar formados por múltiples subvolúmenes que
generalmente están hospedados en varios servidores. Cada subvolumen posee un brick
correspondiente como unidad básica de almacenamiento. Este sistema posee tres tipos
fundamentales de volúmenes:
10. Volúmenes distribuidos: Los archivos son ubicados de forma aleatoria en los bricks que
forman parte del volumen. Pueden haber uno o múltiples servidores hospedando los
bricks, pero cada fichero se encuentra almacenado solo una vez, por lo que la falla de
uno de los servidores puede causar pérdidas de información.
11. Volúmenes replicados: Son creadas copias de los archivos y almacenadas en múltiples
bricks, que se encuentran en diferentes servidores, en el volumen para garantizar la
protección ante fallas de los servidores.
12. Volúmenes fragmentados: Los datos son divididos en partes, distribuidas en múltiples
volúmenes, luego segmentadas y guardados finalmente en los bricks. Esto permite
significativas velocidades de subidas en escenarios de alta concurrencia.
Permite la creación de volúmenes mixtos y de Grupos de Almacenamiento de Confianza que

combinan múltiples servidores de almacenamiento en un volumen distribuido.
2.2 Consistencia
En este sistema no se emplea por defecto el caching en los clientes para poder brindar
multiescalabilidad y una consistencia de caché bien fuerte. Todos los traductores poseen sus
mecanismos propios para mantener un espacio de nombres global. La consistencia de la
información replicada es garantizada mediante el traductor de replicación automática. Este
traductor utiliza bloqueos en los accesos paralelos de los clientes a una misma información para
lograr que los datos que se encuentran alojados en más de un brick sean los mismos.
GlusterFS provee redundancia empleando diferentes niveles de tecnologías RAID como RAID5,
RAID6 y RAID10 o replicación para su utilización en aplicaciones de alto rendimiento. En este
sistema la replicación es realizada a nivel de servidor a través del traductor de replicación
automática, responsable de:
127
Anexos
13. Mantener la consistencia de las copias replicadas.

14. Proveer en caso de fallas una vía para la recuperación de los datos manteniendo al
menos un brick con la información en estado correcto.
15. Servir los datos de forma correcta para que puedan ser realizada las operaciones.
La información de cada servidor de almacenamiento es distribuida o replicada a otros

servidores, basándose en los tipos de volúmenes fijados, a través de escrituras sincrónicas. Los
volúmenes distribuidos emplean valores de redundancia para garantizar la tolerancia ante fallas
de los bricks que los componen. Cada uno posee valores fijados desde su creación. Este valor
determina cuántos bricks pueden encontrarse fuera de servicio y aún así la información se
mantenga. También permite determinar la capacidad del volumen, para su cálculo de se emplea
la expresión:
Capacidad = Tamaño de Brick x(#Bricks - Redundancia)
Todos los bricks que se encuentran distribuidos tienen que tener la misma capacidad. En caso
de que hallan bricks de menor capacidad, al llenarse uno de ellos, no se almacenará más
información en el volumen distribuido del que formen parte. Es importante señalar que en una
configuración con tres bricks con valor unitario de redundancia el volumen tendrá menor
capacidad, alrededor del 66.7% del espacio físico total, y en otra con diez bricks e igual
redundancia, un 90 %. El primer caso brinda mayor fiabilidad a la información ue el segundo.
Este DFS emplea traductores para la detección de fallas a nivel de bricks para identificar las fallas
relacionadas con el sistema de ficheros y de almacenamiento. El traductor de detección de fallas
deshabilita los bricks con problemas sin provocar interrupciones en el funcionamiento de los
nodos hospederos.
Los clientes son capaces de comunicarse con los bricks aún estando caídos, por lo que conocen
de su indisponibilidad solo al ejecutar las operaciones de I/O por las demoras que provoca. Para
evitar este escenario y proveer una mejor detección de fallas se implementa el verificador de
salud para el chequeo constante del estado del DFS lo que implica la verificación funcional del
hardware y del almacenamiento. Los procesos de los bricks, al detectar que su almacenamiento
no responde, dejan de prestar servicio. El demonio glusterd puede detectar si alguno de los
procesos de los bricks se encuentra fuera de servicio. En los volúmenes se muestra el estado de
los bricks.
2.5 Balanceo de carga
El EHA asigna uniformemente y de forma balanceada la información a los diferentes grupos de

almacenamiento lógico de acuerdo a los tipos de volúmenes. Los bricks que son agregados o
removidos del sistema, o los ficheros que son renombrados, pierden las ubicaciones
128
Anexos
anteriormente dadas por el algoritmo hash por lo que conllevan al rebalance de la carga de los
volúmenes, en un proceso que consta de dos fases:
16. Cálculo de nuevas distribuciones de acuerdo a los nuevos bricks y sus características.
17. Migración de los archivos a sus nuevas ubicaciones hash y limpieza de los antiguos
enlaces que no son necesarios.
Usualmente estas dos fases son realizadas conjuntamente. La fase de migración de los
archivos es disruptiva al producir una carga significativa en las I/O por lo que es ejecutada
la fase de cálculo de las nuevas distribuciones y la migración de los datos se produce
paulatinamente sin sobrecargar al sistema.
c. Ceph File System (Ceph) [26]
Ceph es un sistema de ficheros distribuidos de acceso en paralelo, de SLCA, diseñado para

proveer almacenamiento en bloques, ficheros y objetos. Garantiza alto rendimiento y fiabilidad
sin un punto de fallo único, y es escalable hasta el orden de los EB. Es el único sistema de
almacenamiento que posee tres interfaces de acceso: sistema de ficheros con semántica casi
POSIX (CephFS), almacenamiento de objetos usando REST (RADOSGW) y dispositivo de
almacenamiento basado en bloques (RBD). La base de este sistema es RADOS que provee
almacenamiento distribuido basado en objetos, fiable y autónomo. Este sistema emplea una
función de distribución de la información de forma pseudo-aleatoria (CRUSH) que reemplaza
las tablas de ubicación tradicionales. Ceph emplea dispositivos inteligentes de almacenamiento
basados en objetos (OSD) que se encargan de la distribución de las réplicas, de la detección de
fallas y de la recuperación de forma semi-autónoma. Puede ser escalado agregando nodos o
dispositivos de almacenamiento (OSD) y puede llegar a estar formado por más de 10000 nodos.
Los cambios en el tamaño del clúster hacen que el sistema proceda automáticamente a la
recuperación de fallas o al balanceo nuevamente de todos los datos almacenados sin ocurra
ninguna interrupción en los servicios. La interfaz REST es compatible con las aplicaciones de
Amazon S3 y OpenStack, Swift.
3.1 Arquitectura
La arquitectura de Ceph está basada en tres elementos fundamentales que son llamados
demonios; OSD, Monitors (MON) y Metadata Server (MDS). Los OSD se encargan del
almacenamiento de los objetos en el sistema de ficheros local, permiten el acceso a ellos a
través de la red y normalmente están relacionados con un disco físico. Los MON mantienen el
mapa del estado del clúster y de la capa de datos en términos de los grupos de ubicación (PG).
Los MDS se ocupan del manejo de los metadatos del sistema de ficheros (CephFS). El sistema
RADOS constituye la base del funcionamiento de Ceph, aúna al pequeño grupo de MON, y a
129
Anexos
todos los OSD manejando su afiliación al clúster. RADOS dota de inteligencia a los OSD para la
ejecución dinámica en todo el clúster de las tareas de consistencia de la información, de
redundancia del almacenamiento, y de detección y recuperación ante fallas. Garantiza la
consistencia en la distribución y en las lecturas/escrituras de la información. RADOS es el
responsable de la distribución balanceada de la carga de trabajo y de los datos. Emplea el
sistema de ficheros local EBOFS para el almacenamiento de los objetos en los OSD, o sea para
el manejo de la información a bajo nivel. Este sistema provee aplicaciones que permiten acceder
a un sistema de almacenamiento único con semánticas seguras y de alta consistencia. Toda la
información, tanto archivos de los clientes como metadatos, es almacenada en el mismo
sistema de almacenamiento, en diferentes pools; por defecto se crean tres pools: data,
metadata y rbd, que corresponden a cada una de las interfaces.
OSD
Los OSD se encargan de la migración y la replicación de la información, de la detección y

recuperación ante fallas. Permiten la ejecución de lecturas/escrituras directas, de alto
throughput, en paralelo y con un amplio rango de bytes que son configurables de acuerdo a la
naturaleza de la información con la que se trabaja. Aprovisionan colectivamente a Ceph de un
sistema de objetos únicos para el almacenamiento de la información de los clientes y de los
MDS. Utilizan el algoritmo CRUSH para la ubicación de la información y toman las decisiones de
bajo nivel de cada uno de los objetos. Favorecen la multiescalabilidad del sistema y permiten
brindar una mayor tolerancia a fallas al permitir que la replicación se realice a nivel de
dispositivos de almacenamiento.
MDS
Ceph utiliza una arquitectura de metadatos basada en un algoritmo de partición dinámica de

árbol que distribuye el manejo de los metadatos en varios MDS. La distribución de las
responsabilidades se ejecuta de forma inteligente y adaptativa para el manejo dinámico de la
jerarquía de directorios del sistema de ficheros. Permite que el sistema sea multiescalable, casi
de forma lineal, eliminando los problemas relacionados con un único servicio de nombres que
afecta el rendimiento de los sistemas asimétricos. Puede ser escalado en el orden de los cientos
de MDS. Los MDS emplean una simple función para el nombrado de la información la cual les
permite almacenar solo los metadatos relacionados con el número inode, y la estrategia de
distribución y el rango de bytes usados para su posterior localización en el sistema. Esta función
de nombrado de objetos permite que con un pequeño grupo de metadatos pueda obtenerse el
nombre de forma eficiente, simplifica el diseño del sistema y reduce la carga de trabajo de los
MDS. Los demonios MDS se emplean solo para el despliegue de CephFS.
130
Anexos
MON
El funcionamiento de Ceph depende de que los clientes y los OSD tengan conocimiento de la
topología del sistema, o sea de los mapas del clúster, para el acceso a la información. Los MON
se encargan del mantenimiento de los mapas del clúster que incluye los miembros del clúster,
su estado, los cambios que se producen, la salud del sistema, la distribución de la información
y otros. También gestionan las fallas de las que luego se ocupan los OSD, y toman todas las
decisiones en conjunto a través de un algoritmo de consenso distribuido basado en Paxos . El
mapa del clúster está formado por cinco mapas independientes que contienen información
relacionada con cada uno de los elementos fundamentales del clúster y cada mapa mantiene
un historial con los cambios de estado de las operaciones correspondientes.
18. Monitor Map: Está formado por el fsid del clúster, nombre, dirección y el puerto de cada
monitor. Indica la versión del estado actual (epoch), cuando fue creado el mapa y la
última vez que fue modificado.
19. OSD Map: Contiene el fsid del clúster, los datos del momento de creación del mapa y la
última modificación, una lista de los pools, número de réplicas y de PG y una lista de los
OSD y sus estados.
20. PG Map: Posee las versiones de los PG, la marca de tiempo, el último epoch del mapa
OSD, todos los ratio y los detalles de cada PG como el ID, el estado y otros.
21. CRUSH Map: Tiene la lista de los dispositivos de almacenamiento, la jerarquía de
dominios de fallas y las reglas que se utilizan para almacenar los datos.
22. MDS Map: Muestra el epoch del mapa MDS actual, los datos del momento de creación
del mapa y la última vez que fue modificado, el pool que se usa para almacenar los
metadatos, una lista de los servidores de metadatos y una descripción del estado de
estos servidores.
En un clúster debe haber varios monitores para evitar un punto de falla único y el número de
MON tiene que ser impar para que haya quórum. Los MON le asignan un peso a cada uno de
los dispositivos de almacenamiento para controlar el volumen de datos que almacenan y
permitir la distribución uniforme de los datos a través del clúster.
Cliente
Los clientes del sistema de almacenamiento Ceph acceden directamente y en paralelo a la

información almacenada en los OSD. Pueden acceder a través de la interfaz del sistema de
ficheros, del almacenamiento en bloques o basada en objetos, y en dependencia de la interfaz
que utilicen para el acceso está dada su interacción con los diferentes elementos del clúster.
Para el manejo de las ubicaciones de los datos los clientes utilizan el algoritmo CRUSH al igual
que los OSD. Por ejemplo, para el acceso a una información almacenada en el sistema de
ficheros los clientes necesitan conocer el mapa del clúster que poseen los MON y los metadatos
de la información en cuestión que se encuentran almacenados en el MDS, con los cuales
131
Anexos
obtendrían la ubicación empleando el algoritmo CRUSH, para luego iniciar las transferencias
directamente con los OSD. Los clientes interactúan con los MDS solo cuando acceden al sistema
de ficheros.
La distribución de la información en este sistema es determinada utilizando el algoritmo CRUSH

y ubicada mediante el mapeo de los objetos a los diferentes grupos de ubicación (PG) y éstos a
su vez a los OSD de acuerdo a los dominios de fallas y las reglas de replicación establecidas. El
CRUSH es similar a las funciones hash, con la diferencia de que la distribución de los PG es
realizada de forma determinista aunque pseudo-aleatoriamente. Este algoritmo le aporta gran
rendimiento y resistencia al sistema, y permite que el clúster de almacenamiento Ceph pueda
ser escalado, balanceado y recuperado dinámicamente. Emplea dominios de fallas para definir
el CRUSH Map que pueden ser fijados a nivel de disco, servidor y rack para brindar tolerancia a
fallas. Además emplea los pesos de los OSD para controlar la relación entre el volumen de datos
almacenado en cada dispositivo basado en su capacidad o rendimiento y para el balanceo en el
almacenamiento de los datos.
El sistema de almacenamiento Ceph utiliza dos redes de datos para su funcionamiento, una de
acceso público y otra solo para el clúster. Esta arquitectura garantiza el aislamiento de los
procesos de replicación y de estado del clúster, que consumen un significativo ancho de banda,
con los de acceso por parte de los clientes, mejorando el rendimiento y la disponibilidad del
sistema.
CephFS posee una arquitectura asimétrica, localmente centralizada. Este sistema de ficheros
está conformado por demonios MON, MDS y MDS que utilizan el protocolo RADOS de conjunto
con la librería libcephfs para su funcionamiento. Puede ser accedido mediante montaje a nivel
de núcleo en sistemas Linux o a través de FUSE.
Ceph RBD permite el acceso a nivel de bloques a las imágenes que se encuentran distribuidas y
replicadas a través del clúster de almacenamiento. Está provisto con el controlador del
hypervisor KVM.
RADOSGW es la interfaz del sistema de almacenamiento Ceph que permite el acceso a nivel de
objetos a través de aplicaciones S3 y Swift compatibles. Funciona como una capa sobre el
sistema de almacenamiento Ceph que posee sus propios formatos de datos, mantiene las bases
de datos de sus usuarios, la autenticación y el control de acceso, y usa un espacio de nombres
unificado.
3.2 Consistencia
Este sistema para el mantenimiento de la consistencia del almacenamiento realiza limpiezas de

los objetos que se encuentran en los PG. El proceso compara los metadatos de un PG con las
réplicas en PG almacenados en otros OSD, se ejecuta por defecto diariamente y resuelve errores
del sistema de ficheros o bugs de los OSD. También se realiza una limpieza profunda
132
Anexos
semanalmente que compara los datos de los objetos bit a bit y muestra los sectores en discos
que se encuentran en mal estado y no fueron hallados en la limpieza menos profunda. Los OSD
que son marcados como caídos sincronizan la información hacia el disco y ellos mismos salen
de funcionamiento para garantizar la consistencia de los datos. Este sistema de almacenamiento
emplea la política de consistencia de la información writeonce- red-once donde los clientes son
notificados cuando todas las réplicas han sido escritas. En caso de que se produzcan accesos
simultáneos a un mismo archivo y alguno de ellos para realizar una modificación, el MDS
bloquea el acceso de todos los clientes que tienen el archivo en la caché, autoriza la escritura y
luego desbloquea el acceso a dicho archivo, una vez esté modificado.
Los datos son replicados en términos de los PG que se almacenan en tantos OSD como el
número de réplicas que fueron fijadas. El algoritmo CRUSH posee la lista de reglas para la
replicación de los datos. Las políticas de ubicación del CRUSH separan las réplicas de los objetos
a través de diferentes dominios de fallas para mantener siempre alguna réplica en caso de que
ocurran múltiples fallas. Emplea el modelo de actualización de una de las copias y luego propaga
los cambios al resto de los nodos donde se encuentran almacenadas. El cliente envía todas las
escrituras de objetos al primer OSD en los PG primarios que asignan un nuevo número de
versión al objeto y a los PG y reenvían la escritura a cualquier OSD. Luego de que cada réplica
aplica la actualización y responde al primario, el primario aplica la actualización localmente y
entonces el cliente conoce de la culminación de la escritura. El modelo de replicación que
emplea Ceph libera al cliente de las complejidades relacionadas con la sincronización que puede
ser un problema en caso de que se estén ejecutando múltiples escrituras o procesos de
recuperación ante fallas. El cliente solo es notificado del fin de una escritura, una vez escritas
todas las copias de dicha información. La replicación no influye en el consumo del ancho de
banda de los clientes que acceden al sistema al llevarse a cabo a través de la red interna del
clúster. La sincronización que utiliza este sistema retiene su simplicidad en permitir semánticas
de lecturas/escrituras y escrituras compartidas a través de I/O sincrónicas.
Ceph emplea mensajes asincrónicos para la comunicación punto a punto, donde los fallas en
una conexión TCP conllevan a un limitado número de nuevos intentos antes de que la falla sea
reportada a los MON del clúster y delega la responsabilidad de la detección de fallas a los OSD
que almacenan la información. Los OSD intercambian reportes de estado periódicamente con
sus semejantes con los cuales comparten los PG, o sea con pares, para garantizar que cualquier
falla en los dispositivos sea detectada. Los que presentan fallas en muchos casos le comunican
a otros que las poseen y en caso de que no puedan; ocasionalmente los OSD vecinos ejecutan
ping entre ellos, si no hay respuesta, se marca como caído en la lista que llevan los MON y no
se emplea en el almacenamiento de datos, después de algún tiempo es sacado del clúster y
133
Anexos
reemplazado por otro replicándose toda la información del anterior. Las responsabilidades de
un OSD caído o que sea sacado del clúster son pasadas al siguiente OSD en la lista.
3.5 Seguridad
El sistema de almacenamiento Ceph emplea Capability Lists para el control y la autorización de

los accesos basándose en las operaciones de lectura, lectura de caché, escrituras y escrituras
en buffer que serán ejecutadas por cualquiera de los elementos del sistema.
d. Integrated Rule-Oriented Data System (iRODS) [136]
El sistema integrado de datos orientados a reglas (iRODS) es un software de gestión de datos

de código abierto utilizado por organizaciones de investigación y agencias gubernamentales de
todo el mundo. IRODS se publica como una distribución a nivel de producción dirigida al
despliegue en entornos de misión crítica. Virtualiza los recursos de almacenamiento de datos,
por lo que los usuarios pueden tomar el control de sus datos, sin importar dónde y en qué
dispositivo se almacenan los datos. A medida que crecen los volúmenes de datos y los servicios
de datos se vuelven más complejos, iRODS está desempeñando un papel cada vez más
importante en la gestión de datos.
4.1 Arquitectura
IRODS, un sistema centralizado, tiene dos componentes principales: el servidor iCat que
almacena metadatos en una base de datos y maneja las consultas a estos metadatos; Y varios
servidores iRODS que almacenan datos en los recursos de almacenamiento. Un servidor iCat y
varios servidores iRODS forman una zona. Comparado con otros sistemas de archivos
distribuidos, iRODS se basa en el sistema de archivos local de los recursos de almacenamiento
(sistema de archivos Unix, NTFS) y no da formato ni despliega su propio sistema de archivos.
4.2 Nombrado
IRODS almacena el espacio de nombres y metadatos en una base de datos y proporciona

herramientas similares a SQL para consultar los metadatos. Los usuarios pueden ver la misma
jerarquía de archivos y directorios como en el sistema de archivos Unix (por ejemplo,
/home/myname/my_le.txt). IRODS también proporciona herramientas para federar diferentes
zonas, haciendo que los archivos de una zona sean accesibles a clientes de otra zona.
4.3 API y acceso cliente
Los clientes en iRODS necesitan conectarse a un solo servidor (iCat o servidor iRODS), ya que
iRODS garantiza el enrutamiento entre los diferentes componentes. IRODS proporciona una
interfaz de cliente en línea de comandos, un módulo FUSE y algunas API (PHP, Java ...) para
asegurar operaciones de E / S y procesar consultas. De forma similar a los DFS vistos
134
Anexos
anteriormente, los clientes se comunican con el servidor iCat para las solicitudes de metadatos
y directamente con los servidores iRODS para la E / S.
4.4 Consistencia de la Caché
IRODS utiliza un mecanismo WORM. Sin embargo, en algunos casos, los datos podrían
reescribirse con una opción --force. En este caso se proporcionan otras opciones para garantizar
la coherencia: --wlock y --rlock. Estos son bloqueo de escritura y bloqueo de lectura que
permiten bloquear un archivo durante una operación de escritura o lectura.
4.5 Replicación y sincronización
De forma predeterminada, iRODS no replica automáticamente los datos. En su lugar

implementa un comando de replicación (irepl) que se puede ejecutar manualmente como otras
operaciones habituales (iput, iget ...). Sin embargo, iRODS es un sistema personalizable, es
posible crear reglas, es decir, diseñar pequeños comandos que se ejecutarán después de una
operación específica. Por ejemplo, crear una regla que ordene al sistema replicar datos después
de su creación. En este caso, las copias se realizan de forma síncrona. Sin embargo, la política
de colocación es responsabilidad de los usuarios. IRODS también permite a los usuarios crear
grupos de recursos de almacenamiento y elegir en qué grupo quieren almacenar datos y
réplicas.
4.6 Balance de carga
En iRODS, los recursos de almacenamiento pertenecen a un grupo predeterminado o a un grupo

creado por los usuarios. Estos recursos se monitorean para medir la actividad de los servidores.
Una regla se ejecuta periódicamente para determinar cuándo un servidor está sobrecargado,
de acuerdo con los parámetros configurables (carga de la CPU, espacio en disco utilizado ...) y
permite a iRODS elegir el almacenamiento adecuado en un grupo para colocar nuevos datos.
Sin embargo, es posible decir a iRODS para evitar o obligar a que los datos se coloquen en un
recurso específico usando otras reglas. Los usuarios también pueden mover datos de un
almacenamiento a otro. Por lo tanto, al igual que la replicación, los usuarios pueden elegir cómo
equilibrar el sistema.
4.7 Detección de fallas
IRODS se implementa como una forma peer-to-peer. Por lo tanto, los servidores pueden
comunicarse juntos para detectar cuando un servidor no está disponible. En este caso, el
servidor inexacto se elimina del grupo de recursos de almacenamiento y el cliente no puede
realizar ninguna operación de E / S desde o hacia este servidor.
135
Anexos
e. Lustre File System (Lustre) [86]
El sistema de archivos Lustre es un sistema de archivos paralelo de código abierto que soporta
muchos requisitos de entornos de simulación HPC de liderazgo mundial.
5.1 Arquitectura
Luster es un sistema distribuido centralizado que se distingue de los DFS actuales, ya que no
proporciona ninguna copia de datos y metadatos. En su lugar, Lustre elige Almacenar metadatos
en un almacenamiento compartido denominado Meta de metadatos (MDT) adjunto a dos
servidores de metadatos (MDS), ofreciendo así una conmutación por error activa / pasiva. MDS
son los servidores que manejan las solicitudes a los metadatos. Los datos se gestionan de la
misma manera. Se dividen en objetos y se distribuyen en varios Objetos de almacenamiento de
objetos compartidos (OST) que se pueden conectar a varios servidores de almacenamiento de
objetos (OSS) para proporcionar una conmutación por error activa / activa. OSS son los
servidores que manejan las solicitudes de E / S.
5.2 Nombrado
El espacio de nombre global único del Lustre es proporcionado al usuario por el MDS. Lustre usa
inodes, como HDFS o MooseFS, y atributos extendidos para asignar el nombre del objeto de
archivo a sus OSTs correspondientes. Por lo tanto, los clientes serán informados de qué OST
debe consultar para cada uno de los datos solicitados.
5.3 API y acceso de cliente
Luster proporciona herramientas para montar todo el sistema de archivos en el espacio del
usuario (FUSE). Las transferencias de archivos y las consultas de procesamiento se realizan de
la misma manera que los otros DFS centralizados, es decir, solicitan al MDS que ubique los datos
y realice directamente las E / S con los OST apropiados.
5.4 Consistencia de la Caché
Lustre implementa un Distributed Lock Manager (DLM) para administrar la coherencia del
caché. Se trata de un sofisticado mecanismo de bloqueo que permite a Lustre admitir acceso
concurrente de lectura y escritura. Por ejemplo, Lustre puede elegir conceder bloqueo de
escritura en un directorio con poca contienda. El bloqueo de retroalimentación permite a los
clientes almacenar en caché un gran número de actualizaciones en la memoria que se asignarán
al disco más tarde, reduciendo así las transferencias de datos. Mientras que en un directorio
con acceso simultáneo, Lustre puede elegir realizar cada solicitud de uno en uno para
proporcionar una fuerte consistencia de datos.
5.5 Replicación y sincronización
Lustre no garantiza la replicación. En su lugar, se basa en software independiente.
136
Anexos
5.6 Balance de carga
Lustre proporciona herramientas sencillas para el equilibrio de carga. Cuando un OST está
desequilibrado, es decir, utiliza más espacio de disco que otros OST, el MDS elegirá OST con más
espacio libre para almacenar nuevos datos.
5.7 Detección de Fallas
Lustre difiere de otros DFS porque se detectan fallos durante las operaciones de los clientes
(consultas de metadatos o transferencias de datos) en lugar de detectarse durante las
comunicaciones de los servidores. Cuando un cliente solicita un archivo, primero entra en
contacto con el MDS. Si este último no está disponible, el cliente pedirá a un servidor LDAP que
sepa qué otros MDS puede cuestionar. A continuación, el sistema realiza una conmutación por
error, es decir, el primer MDS está marcado como muerto y el segundo se convierte en activo.
Un fallo en OST se hace de la misma manera. Si un cliente envía datos a un OST que no responde
durante un tiempo determinado, será redirigido a otro OST.
137
Anexos
Anexo E. RNF para el diseño del SA
Leyenda:
ROJO: Concernientes al cliente o los administradores. Preguntado en forma de encuesta en el Epígrafe 2.5
AZUL: Concernientes al diseñador del SA.
VERDE: Evaluado en las pruebas al SA en el Epígrafe 2.10
MORADO: Buenas prácticas a mantener durante el uso del SA.
Tabla 32 RNF del SA
Dimensiones Categoría Atributos Descripción Métricas Acción
Indica la capacidad del SA para

Vertical incrementar su capacidad agregando
hardware en adición al existente.
Adaptabilidad Escalabilidad Tamaño del clúster: Número máximo de nodos en clúster que Documentación
soporta el SA. del SA.
Los SA pueden ser escalables
Restricciones de localización
horizontalmente siempre que permitan
Restricciones de espacio
ser agregados nodos de almacenamiento
Horizontal Restricciones arquitectónicas Preguntas al
sin que afecte la integridad de la
Restricciones de armarios/bastidores cliente. (Epíg.
información y se incremente la capacidad
Restricciones medioambientales 2.5)
del sistema.
Restricciones eléctricas
Restricciones de consumo eléctrico
138
Anexos
Restricciones de topologías de red

Restricciones de presupuesto
Pregunta
Es la capacidad que tiene el SA para
directa al
fácilmente interactuar con otros procesos ¿Soporta CDMI, REST o Protocolo de Acceso Simple a Objeto
Interoperabilidad diseñador del
o servicios del mismo proveedor o de (SOAP)?
SA.
proveedores diferentes.
¿Tiene Soporte para Interfaces de Programación de Aplicaciones
(API)?
Es la habilidad de añadir o eliminar Preguntas al
¿Tiene soporte de pluggins?
Compatibilidad Flexibilidad funcionalidades o características al SA cliente. (Epíg.
¿Posee facilidad de integración con herramientas de terceros?
existente. 2.5)
¿El sistema posee estructura modular?
¿El sistema es una solución de SLCA?
Se refiere al soporte que tiene el SA para
diferentes estándares, tecnologías, y sus ¿Cuántos SO le dan soporte a la solución? Preguntas al
Compatibilidad evoluciones con el propósito de ser ¿Qué gestores soportan la solución? cliente. (Epíg.
compatible con diferentes proveedores 2.5)
de hardware y soluciones de software.
¿Qué espacio en GB deberá asignarse a utilizar por las instancias
Expresa las limitaciones de los recursos virtuales en total? ¿Qué nivel de redundancia deberá tener?
Preguntas al
de almacenamiento o la máxima cantidad ¿Qué espacio en GB deberá asignarse para las salvas? ¿Qué nivel
Capacidad cliente. (Epíg.
de recursos de almacenamiento de redundancia deberá tener?
2.5)
disponibles. ¿Qué espacio en GB deberá asignarse para ofrecer DSaaS? ¿Qué
nivel de redundancia deberá tener?
Qos Desempeño
% CPU usada del nodo
% RAM usada del nodo
Es el porciento de la capacidad disponible % Uso de cada disco que compone el SA Monitoreo
Utilización
total que está siendo utilizada. % Disco usado del clúster de almacenamiento permanente
% usado y libre para salvas.
% Usado Ancho de Banda de la Red SA.
139
Anexos
-Throughput de la red del SA: Cantidad de datos

Libre de errores transferidos por unidad de
Tiempo en la red del SA.
-Throughput de la red de acceso al SA: Cantidad
de datos libre de errores transferidos
Pruebas al SA.
Ofrece una medida de la velocidad de E/S por unidad de tiempo en la red de acceso al SA.
Throughput
de información que posee el sistema. -Throughput de E/S en disco: Velocidad de operaciones de
escritura, lectura, reescritura, relectura de forma secuencial y
aleatoria respectivamente.
-IOPS de los discos: cantidad de operaciones de
e/s capaz de realizar los discos que componen
el SA.
-Tiempo de respuesta: Tiempo entre una solicitud de una
información y su obtención.
-Tiempo de aprovisionamiento de un Disco: Tiempo transcurrido
desde que es solicitado un disco hasta que es aprovisionado listo
para su operación.
-Tiempo de incremento de capacidad de un disco: Relacionado
Tiempo entre una solicitud de una
Tiempo de respuesta con la elasticidad, mide el
información y su obtención.
tiempo que demora el proveedor en satisfacer una solicitud de
incremento de recursos.
PROMEDIO Pruebas al SA.
-Tiempo de Respuesta Promedio: Promedio de todos los tiempos
de respuesta de cada uno de los parámetros anteriores de forma
independiente.
% de tiempos de respuesta: % de tiempos de respuesta que no
se consideran demoras.
Se consideran aquellos tiempos de
Umbral de la demora: Valor de tiempo que marca la diferencia
Latencia o Demora respuesta que sobrepasan umbrales
entre un tiempo de respuesta aceptable y una demora.
preestablecidos.
Demora promedio: Valor promedio de todas las demoras
detectadas.
Potencia total consumida por el SA
Es la cantidad de recursos energéticos y
Capacidad utilizada/Capacidad total en %
de utilización empleados de forma
Eficiencia GB/watt Pruebas al SA.
óptima por el SA para realizar sus
IOPS/watt
operaciones.
Mbps/watt
140
Anexos
A tener en cuenta a la hora de elegir una solución el sistema

debe tener soporte para:
Thin provisioning Documentación
Deduplicación de datos del SA.
Compresión de datos
Uso de SSD para mejor rendimiento y bajo consumo energético
Evalúa el nivel de disponibilidad del SA.
% servicio activo Donde TTO y TTSSA corresponden al Tiempo Total de Monitoreo

Observación y Tiempo Total de Suspensión del SA
respectivamente.
Es la habilidad del SA de mantenerse en

Tolerancia a fallos operación ante el fallo planificado o no Crear fallos en el sistema para comprobar su tolerancia. Pruebas al SA.
de uno o más componentes.
Disponibilidad Para ello se define el Índice de Recuperación ante Fallos (IRAF) el
cual puede ser calculado mediante la Ecuación:
Es la habilidad que tiene el SA de
recuperarse ante la ocurrencia de fallos
Recuperación ante fallos Pruebas al SA.
(intencionales, no intencionales) que
afecten su operación normal. Donde MTTSR y MxTTSR corresponden al tiempo promedio para
la restauración del servicio y el tiempo máximo para la
restauración del servicio respectivamente
Es la habilidad que tiene un SA de
¿Qué tipos de políticas de replicación o políticas de redundancia Documentación
Confiabilidad trabajar sin fallos bajo condiciones dadas
o algoritmos para ello posee el sistema? del SA.
durante cierto período de tiempo.
¿Cómo califica la independencia de dispositivo para acceder al
servicio?
Caracteriza la independencia, ¿Cómo califica la independencia de plataforma para acceder al
accesibilidad, nivel de personalización y servicio? Preguntas al
Factibilidad Usabilidad usuario final facilidades de operación que experimenta ¿Cómo califica la facilidad de uso del servicio? cliente. (Epíg.
el usuario final cuando hace uso del ¿Cómo evalúa la posibilidad de personalización que ofrece el 2.5)
DSaaS. servicio?
¿Cómo califica los esfuerzos requeridos para aprender a usar el
servicio?
141
Anexos
Caracteriza los esfuerzos requeridos por

¿Cómo califica la facilidad de instalación del sistema?
el personal administrativo para operar Preguntas a los
¿Cómo califica la curva de aprendizaje de gestión del sistema?
administradores con los recursos de las TIC. Comprende administradore
¿Cómo califica las opciones de gestión del sistema (Web
aspectos como la facilidad de instalación s. (Epíg. 2.5)
CLI)?
y operabilidad del SA.
¿Cómo evalúa el nivel de consolidación de los proveedores de la
Es el grado de prestigio, competencia y
solución del SA?
calidad que tienen los Preguntas al
Consolidación de los ¿Cómo evalúa el nivel de consolidación de los proveedores del
proveedores/comunidades del hardware cliente. (Epíg.
proveedores/comunidad sistema de gestión del SA?
y software que sustentan la 2.5)
¿Cómo evalúa el nivel de consolidación de los proveedores del
infraestructura del SA.
equipamiento del SA?
¿Cómo evalúa el nivel de madurez de las soluciones de
Está relacionada con el tiempo que lleva
Robustez servidores del SA?
una solución de almacenamiento en Preguntas al
¿Cómo evalúa el nivel de madurez de la solución del sistema de
Madurez de las Soluciones producción, el número de versiones del cliente. (Epíg.
gestión del SA?
software así como el intervalo de tiempo 2.5)
¿Cómo evalúa el nivel de madurez de las soluciones de
promedio entre una versión y otra
equipamiento de red del SA?
Está relacionado con la cantidad de
¿Cuán amplia y actualizada es la bibliografía de soporte que Sitio Oficial de
Soporte del proveedor información que ofrecen los proveedores
brindan los proveedores de las soluciones? la Solución
acerca de sus soluciones.
La métrica que se propone para evaluar este requerimiento es el
Valor Actual Neto (VAN) que permite calcular el valor presente
de un determinado número de flujos de caja futuros, originados
por una inversión.
Como su nombre lo indica esta técnica se

Factibilidad económica Análisis costo-beneficio basa en sustraer a los beneficios los Manualmente
Donde Bt y Ct representan los valores de beneficios y costos en
costos asociados con ellos
cada uno de los períodos 𝑡, 𝑟 representa a la tasa de descuento e
I0 es la inversión inicial.
VAN > 0 La inversión produciría ganancias por encima de la

rentabilidad exigida (r). El proyecto puede aceptarse.
VAN < 0 La inversión produciría pérdidas por debajo de la
rentabilidad exigida (r). El proyecto debería rechazarse.
142
Anexos
VAN = 0 La inversión no produciría ni ganancias ni pérdidas.

Dado que el proyecto no agrega valor monetario por encima de
la rentabilidad exigida (r), la decisión debería basarse en otros
criterios, como la obtención de un mejor posicionamiento en el
mercado u otros factores.
Es útil para evaluar las consecuencias

Retorno de la inversión Manualmente
financieras de una inversión. En la medida que ROI es más alto significa que la inversión ha
sido satisfactoria y además el valor indica cuántas veces supera
la ganancia a la inversión.
La siguiente ecuación muestra la expresión para n años.
El CTP cuantifica el impacto financiero de

Costo total de la propiedad desplegar un producto de TIC a lo largo Manualmente
de su ciclo de vida. Para tomar decisiones entre varias soluciones el CTP constituye
una métrica útil. Por ejemplo, si una de las alternativas se basa
en soluciones de SLCA los costos directos disminuyen
significativamente, pero a la vez puede crear un compromiso en
los costos indirectos debido a que en ese escenario la
preparación del personal debe ser mayor.
Es la capacidad del SA de proteger los
datos contra el acceso no autorizado.
Sólo aquellos que deberían tener acceso
Confidencialidad
(leer, ver, explotar, o simplemente saber
que un dato en particular existe)
realmente obtendrá ese acceso.
Seguridad Seguridad
Es la capacidad del SA de proteger la
información de haber sido modificados
por partes no autorizadas o de formas no
Integridad
autorizadas. La modificación incluye
escribir, cambiar, cambiar el estado,
eliminar y crear activos
143
Anexos
El atributo de disponibilidad, con

respecto a la seguridad, indica la
capacidad del SA de garantizar el acceso
de la información a las partes autorizadas
en los momentos apropiados.
Disponibilidad El atributo de disponibilidad indica las
habilidades del SA de:
- denegar el acceso ilegítimo a los datos,
- impedir que las entidades maliciosas
controlen, destruyan o dañen la
información.
Permite al SA que cuando una
información es enviada, el receptor
puede probar que dicha información fue
enviada por el presunto emisor. De
No Repudio
manera similar, cuando una información
es recibida, el remitente puede probar
que la información fue recibida por el
presunto receptor.
El anonimato es la capacidad de ocultar
Anonimato información cuando no hay necesidad de
revelarlas.
Privacidad Es la capacidad del sistema para asegurar
Inobservabilidad que un observador no pueda identificar o
inferir la identidad de las partes
involucradas en una transacción.
144
Anexos
Anexo F. Estructura para las pruebas [38]
A continuación, se definen los elementos que deben integrar un proyecto de pruebas y las
recomendaciones para su elección:
1. Nombre de la prueba: debe ser un nombre corto e ilustrativo.

2. Tipo de prueba: se refiere a si la prueba a realizar es por ejemplo una prueba de carga de trabajo,
de funcionamiento o de microbenchmark.
3. Propósito de una línea de pruebas: define para qué se están realizando las pruebas. Abarca las
posibilidades de detección de fallos, comparaciones de infraestructura, caracterización de
infraestructuras y evaluación de diseños.
4. Objetivo de la prueba: define escuetamente lo que se debe lograr en la prueba, debe ser
alcanzable y realista.
5. Parámetros a ser medidos: Define las métricas a obtenerse durante la realización de la prueba.
De estas métricas dependen los recursos a emplearse y el tiempo de la prueba. La definición de
umbrales se realiza en este paso también, recalcando su importancia y el hecho de que deben
definirse previamente a las pruebas. Los umbrales son relativos a los objetivos del negocio de
la entidad, por lo que se recomienda seleccionarlos basándose en garantizar el cumplimiento
de los SLA definidos.
6. Duración de la prueba: Tiempo estimado de duración de la prueba, incluyendo configuraciones
de despliegue y de limpieza. Se recomiendan duraciones de las pruebas acordes al tipo de
prueba a realizar, teniendo en cuenta el tiempo necesario para la configuración e instalación de
las herramientas y el tiempo de duración de la fase de pruebas en sí. Las fases de pruebas para
pruebas de benchmark no deben ser menores de 2 horas, donde en dependencia de la
herramienta se logran cubrir todas las métricas. Para las pruebas de carga, se recomiendan
duraciones cortas de no más de 30 minutos por prueba, con un tiempo óptimo de 15 minutos
por prueba, para garantizar la recolección de los datos necesarios y no poner en riesgo los
servicios desplegados en la NP.
7. Número de iteraciones a realizar: Para ajustar los resultados se deben realizar múltiples corridas
de una misma prueba.
8. Medios a emplear para las pruebas: especifica aquellos recursos de software, hardware,
logísticos y humanos necesarios. Incluye las herramientas necesarias. Para la selección de las
herramientas se recomienda emplear SLCA, por su flexibilidad, bajos costos de implementación
y fiabilidad. Se recomienda emplear herramientas que no dependan de una conexión a Internet
para su empleo, en aras de garantizar la portabilidad de las pruebas. Se sugiere emplear
herramientas de probada efectividad en la industria, con interfaces gráficas siempre que sea
posible en aras de la usabilidad y compatibles con las métricas definidas en el plan de pruebas.
Se recomienda colocar las herramientas de generación de cargas en nodos capaces de ejecutar
las cargas que se desean, con el objetivo de que los perfiles de carga no se vean limitados por
145
Anexos
el hardware subyacente del generador. Para ellos se recomienda desplegarlas sobre equipos
con al menos un CPU Intel Core i5 y cuatro GB de RAM. El autor de este trabajo recomienda no
emplear herramientas del mismo proveedor que la solución de NP, por considerar que los
resultados pueden estar afectados por la parcialidad del mismo. En adición, se recomienda que
el hardware para realizar las pruebas no cambie durante el período de pruebas, para evitar
incongruencias en los resultados.
9. Descripción de la prueba: se compone de distintas etapas, instalación y configuración del
escenario, realización de la prueba, limpieza del escenario, consistente en la eliminación de las
instalaciones y configuraciones realizadas para la prueba; agregación y cálculo de métricas
finales. Debe ser clara y concisa, en dependencia de los recursos a emplear y del tiempo
definido.
10. Análisis de los resultados: Se propone realizar un análisis de los resultados compuesto por cuatro
etapas: ordenamiento de los resultados, análisis estadísticos de los resultados, comparación de
métricas con estándares de la industria e incorporación de los resultados a BD y conclusiones.
Anexo G. Pruebas de utilización de las aplicaciones
Entornos en desarrollo:
146
Anexos
Nombre de la prueba: Prueba de utilización de recursos por MV independiente.

Tipo de prueba: Carga y monitorización. Se recomienda este tipo de prueba debido a la
necesidad de determinar el consumo de recursos para los distintos tipos de carga a los que
puede ser sometido la NP.
Objetivo de las pruebas: Especificar el consumo de recursos de cómputo, almacenamiento y red
de la Nube para diferentes tipos de carga de forma independiente para cada MV.
Duración: 3 horas. (descartando los resultados de la primera y última media hora) La duración
de esta prueba se basa en las recomendaciones realizadas por VMware para la aplicación de
pruebas del tipo VMmark. Se considera como el tiempo ideal para la realización de pruebas por
tile, considerando que los resultados de la primera y última media hora se pueden ver afectados
por procesos derivados de la propia fase de configuración.
Número de iteraciones: 10. Se recomienda este número de iteraciones para estabilizar los
resultados de las pruebas y evitar aleatoriedades en ellos.
Parámetros a ser medidos y medios a emplear:
La Tabla G.1 muestra las métricas de utilización a recogerse por MV independiente.
Los parámetros a ser medidos se detallan en la Tabla 2.3. Como herramienta para la realización
de las pruebas se recomienda emplear herramientas de monitorización de la infraestructura
presentes en el GN para evaluar la utilización de las distintas MV, en conjunto con herramientas
de gestión de red e infraestructura independientes de la plataforma de NP para monitorizar las
aplicaciones que proveen los servicios, específicamente la herramienta Zenoss. El autor de este
trabajo considera que la herramienta Zenoss de SLCA presenta las métricas más completas,
tiene una alta usabilidad y presenta una amplia penetración en el mercado y la industria. Sin
embargo, esta herramienta requiere el uso de contenedores Docker, no siempre factible en
instituciones con uso de internet medido y 20 GB de RAM en el nodo donde se ejecute, siendo
poco factible para entornos de escasos recursos de cómputo para los cuales se recomienda
Zabbix, una herramienta de SLCA, muy completa y que consume menos recursos que Zenoss.
Sin embargo, el autor de este trabajo reconoce que la usabilidad de Zabbix no es tan buena
como la de Zenoss, siendo necesarias configuraciones complejas y complementos externos a la
herramienta.
Tabla G.1 Métricas de utilización por MV.
Subsistema Parámetros Herramientas
%usado_CPU_nodo Se recomienda monitorizar la
CPU %usado_CPU_clúster infraestructura empleando las
%libre_CPU_nodo herramientas que ofrezca el GN, y para
%usado_RAM_nodo comprobar los resultados complementar
Memoria %usado_RAM_clúster con la herramienta Zenoss para sistemas
%libre_RAM_nodo que cuenten con 20 GB de RAM para
147
Anexos
E/S de disco %usado_disco dedicar al sistema de gestión de red.

%libre_disco Para aquellos sistemas que no cuenten
Red % de uso del ancho de con los recursos requeridos se
banda recomienda Zabbix.
Se requiere además Apache JMeter como generador de carga para la realización de las pruebas.
Se necesita disponer de igual número de nodos de prueba que de generación de cargas.

Elaborar un tile de pruebas con las MV y servicios indicados, empleando la misma definición de
tile empleada por SPEC. Dicho tile será desplegado sobre el diseño realizado y sometido a
pruebas que evalúen los KPI definidos en la Tabla G.1. La creación del tile varía de acuerdo a los
elementos del mismo, siendo deseable que este tenga al menos seis MV y menos de 15, para
lograr una determinada simplicidad en las configuraciones a realizar. En todos los tiles definidos
se agregará una MV de standby, con datos que se extraerán de las necesidades del cliente.
Las características del SO y las aplicaciones escogidas para desplegar los servicios deben
coincidir con las que el cliente pretende emplear para añadir fidelidad a los resultados.
1. Instalar individualmente los servicios a probar, empleando para ello las aplicaciones y
dimensionamiento definidas por el usuario. Se recomienda actualizar las aplicaciones
instaladas a la versión más reciente empleando para ello utilidades como apt-get o aptitude.
2. Instalar JMeter para HTTP, FTP, Proxy, POP, IMAP y SMTP; y Namebench para DNS. Los
generadores de carga deben instalarse en distintos nodos, uno por cada MV integrante del
tile de pruebas. El número de hilos, número de usuarios a simular, de cada JMeter se
determinará en base a los datos recogidos. Los tiempos de ascenso de las cargas y el número
de estas serán definidas por los perfiles de carga a aplicar. Definir recuperadores de datos
en el JMeter de tipo Resumen de operaciones y Gráfico de Resultados.
3. Instalar frontend de Zenoss y los agentes en todos los elementos de la infraestructura. En
escenarios donde no sea posible, emplear Zabbix, instalando el frontend en un equipo no
sometido a pruebas, instalando y configurando agentes en todos los elementos de la red,
asociados a las pruebas. Se recomienda el empleo de agentes de Zabbix, por encima de las
configuraciones basadas en SNMP, debido a las facilidades de configuración y las
funcionalidades que ofrece, entre ellas facilidades para definir frecuencia de petición de
datos y plantillas para cada servicio disponibles para monitorización por agente. Para
aquellos equipos donde no sea posible instalar agentes de Zabbix, se recomienda el uso de
SNMP con las Bases de Información Gestionada (MIB26) propietarias de los fabricantes del
26
Siglas correspondientes al término en inglés: Management Information Base.
148
Anexos
equipo, debido a que estas usualmente ofrecen más información que las MIB
estandarizadas.
4. Las plantillas, elementos y disparadores pertinentes deben ser instalados.
Pruebas:
1. Aplicar perfiles de carga ascendente durante 30 minutos y posteriormente detener las
pruebas por un intervalo de 10 minutos. Aplicar perfiles de carga descendente durante 30
minutos y posteriormente detener las pruebas durante 10 minutos.
2. Aplicar perfiles de carga por picos durante 30 minutos en intervalos de 5 minutos cada uno
de carga y descanso.
3. Esperar un intervalo de 10 minutos y emplear perfiles de sobrecarga, durante 10 minutos
con descansos de 1 minuto (durante 3 iteraciones).
4. Recoger las métricas definidas de los generadores de carga y las herramientas de gestión.
1. Detener todas la MV desplegadas con el servicio y eliminarla.
2. Detener todos los procesos de generación de carga dispuestos.
1. Calcular media, máximo, desviación estándar y umbral del 95 % percentil para cada valor de
las métricas.
Entornos en producción:
Nombre de la prueba: Prueba de utilización de recursos por MV y servicio independiente.
Tipo de prueba: Monitorización.
Objetivo de las pruebas: Especificar el consumo de recursos de cómputo, almacenamiento y red
de la Nube para los tipos de carga presentes en la NP de forma independiente para cada MV
que contiene cada servicio y para cada servicio.
Duración: Permanente.
Parámetros a ser medidos y medios a emplear:
Los medios a emplear y métricas a recoger son las mismas que para entornos en producción,
con la excepción de que no es necesario emplear JMeter pues no se generará carga para este
escenario.
1. Identificar métricas y herramientas a emplearse para recogerlas.
2. Instalar el nodo frontend de Zenoss o Zabbix en un nodo físico independiente a los
empleados para las pruebas.
3. Configurar agentes de las herramientas de gestión en todos los nodos de la NP,
configurando los elementos, plantillas y disparadores necesarios para monitorizar las
métricas establecidas para cada servicio.
149
Anexos
4. Configurar vía SNMP aquellos elementos de la red que no puedan configurarse empleando
agentes para integrarlos al sistema de gestión.
Pruebas:
1. Monitorizar las métricas definidas en la Tabla G.1 durante todo el tiempo que se ha
encontrado activo el sistema de gestión de la NP, específicamente en aquellos intervalos de
tiempo de funcionamiento habitual del sistema como días laborables de 8 am a 6 pm, para
obtener tendencias y comportamientos habituales de la infraestructura.
2. El tiempo de duración de la prueba, para obtener métricas confiables debe ser de al menos
un mes, para contar con datos para analizar de cuatro semanas y evitar aleatoriedades
debidas a eventos especiales o días de alto tráfico.
1. Se recomienda no realizar limpieza de este escenario, pues toda la NP debe contar con un
sistema de gestión de red y de infraestructura. En casos donde la red se vea muy cargada
por el sistema de gestión se recomienda al terminar las pruebas bajar el tiempo de chequeo
de métricas del sistema de gestión a valores que impacten menos el desempeño de la red.
1. Las herramientas de gestión ofrecen métricas agregadas durante un período definido por el
usuario.
La agregación de métricas se realiza de forma similar a la prueba de utilización de entornos en

desarrollo.
150
Anexos
Anexo H. Útiles tomados del libro Top-Down de Cisco
Para el tipo de aplicación, puede utilizar cualquier texto apropiado que describa el tipo de
Aplicación, o puede clasificar la aplicación como una de las siguientes:
■ Correo electrónico ■ Imagen de documentos
■ Proxy Web ■ Control de inventario y envío
■ Transferencia de archivos, compartición y ■ Telemetría
acceso ■ Respuesta de voz interactiva (IVR)
■ Acceso a la base de datos y actualización ■ Mensajería unificada
■ Navegación web ■ Edición electrónica
■ Juego de red ■ Publicación en la Web
■ Terminal remoto ■ Pizarra electrónica
■ Calendario ■ Emulación de terminal
■ Imágenes médicas ■ Directorio en línea (guía telefónica)
■ Videoconferencia ■ Aprendizaje a distancia
■ Video bajo demanda (VoD) ■ Punto de venta (tienda minorista)
■ Vídeo de multidifusión programado ■ Comercio electrónico
■ Vídeo de cámara de vigilancia y seguridad ■ Modelado financiero
■ Voz de Internet o Intranet (telefonía IP) ■ Gestión de recursos humanos
■ Internet o fax intranet ■ Fabricación asistida por computadora
■ Entrada de pedido de cliente ■ Control de procesos y planta de fábrica
■ Informes de gestión ■ Diseño asistido por computadora
■ Seguimiento de ventas
151
Anexos
Anexo I. Características del Almacenamiento Definido por Software (SDS)
El Almacenamiento Definido por Software (SDS) es un término de marketing para software de

almacenamiento de datos informáticos para el aprovisionamiento basado en políticas y la
administración del almacenamiento de datos independientemente del hardware subyacente.
El almacenamiento definido por software normalmente incluye una forma de virtualización de
almacenamiento para separar el hardware de almacenamiento del software que lo administra.
El software que permite un entorno de SDS también puede proporcionar administración de
políticas para funciones como la de duplicación de datos, la replicación, el thin provisioning, las
instantáneas y la copia de seguridad. [137] [103]
En [139] [140] [141] se plantean algunas de sus características:
• Control centralizado y sencillo: Este es el resultado de un sistema, con una interfaz consistente,
para administrar más o el mismo almacenamiento. Las características clave de una
infraestructura bien definida y definida por software, especialmente flexibilidad y facilidad de
cambio, hacen de SDS un elemento fundamental ideal de una NP.
• Arquitecturas multi-escalables: Los sistemas con arquitecturas multi-escalables permiten

agregar y eliminar recursos dinámicamente.
• Heterogeneidad: Muchas herramientas SDS gestionarán un entorno heterogéneo, eliminando

así las restricciones de elementos tales como ubicaciones de datos, tipos de datos, aplicaciones
o tipos de almacenamiento.
• Economía: el software SDS puede reducir los costos. Cada vez que una organización compra
almacenamiento tradicional, paga tanto el hardware como el software de gestión propietario
asociado. Haciendo una sola inversión de software lógico para administrar todo el hardware de
almacenamiento, una organización puede reducir tanto su OpEx como su CapEx . Y con las
economías de escala que trae SDS, los administradores de almacenamiento / sistema pueden
gestionar invariablemente más datos de orden de magnitud que antes, así como lograr una
mejor utilización de recursos.
• Políticas de almacenamiento: Las políticas de control se dividen en dos capas, la capa de

usuario y la de control del almacenamiento. El usuario especifica la QoS en términos de
operaciones de Entrada/Salida realizadas Por Segundo (IOPS), latencia, número de fallas a
tolerar, fiabilidad y disponibilidad. La capa de control también ejecuta decisiones inteligentes
de almacenamiento acorde a la necesidad de la aplicación de mantener los requerimientos de
QoS.
• Recursos de almacenamiento como un único grupo: Es una de las características distintivas de

los SDS donde independientemente de las capas inferiores el almacenamiento se muestra como
uno solo que ocupa todo el sistema. Puede accederse a las capas inferiores desde cualquier
152
Anexos
punto. Al ser un grupo único los recursos pueden ser optimizados de acuerdo a las necesidades
de la aplicación.
• Programabilidad/automatización: La capa de control de los SDS posee programabilidad para

poder satisfacer las necesidades de las aplicaciones. La programabilidad permite actuar sobre
los servicios y manejar los recursos. La capa de control también puede sobrescribir las políticas
de usuario basada en el comportamiento de las aplicaciones. Por ejemplo, si la solicitud de un
usuario posee una IOPS que no puede ser soportada por la aplicación, la capa de control puede
decidir reducir la máxima IOPS para esa solicitud, utilizando los recursos disponibles
eficientemente.
• Hardware de propósito general: El crecimiento de la información y la incapacidad de las

tecnologías de almacenamiento tradicionales de adaptarse a estas condiciones conllevan a la
aparición de arquitecturas que puedan ser desplegadas sobre hardware de propósito general
sin afectar el rendimiento del sistema. Esto conlleva a que se pueda enfrentar el problema de
crecimiento de la información mediante la reutilización de hardware existente e inversiones
inferiores.
El SDS puede implementarse a través de dispositivos a través de una SAN, o implementarse

como una NAS, o utilizando almacenamiento basado en objetos así como su capacidad de
integrarse con los gestores de Nube.
153
Anexos
Anexo J. Características principales de NAS y SAN
Características y ventajas de NAS [64]:
*Soporte para múltiples protocolos: NAS soporta diferentes protocolos, entre ellos NFS para
Unix, CIFS para Windows y Protocolo de Trasferencia de Hipertexto (HTTP) para la web.
NAS posee fundamentalmente las siguientes características [64]:
*Simplicidad: la instalación y explotación de un dispositivo NAS es, casi literalmente, plug-and-

play. Esta facilidad de uso resulta en pocos errores de operación, de configuración y de gestión
del sistema.
*Alta disponibilidad: muchos sistemas NAS tienen incorporados capacidades de tolerancia a

fallos, para proveer soluciones altamente disponibles. Algunas de estas soluciones emplean
sistemas de almacenamiento RAID tolerantes a fallos, sumados a la tolerancia a fallos contenida
en la función de control propia de NAS.
*Escalabilidad: un sistema NAS es fácilmente escalable en capacidad.
*Desempeño: típicamente NAS permite múltiples conexiones de red. Esto permite el soporte
concurrente de múltiples redes y permite a más usuarios estar conectados a un elemento de
almacenamiento común.
*Datos compartidos: una de las funciones básicas de NAS es permitir compartir datos mediante
la implementación de un sistema de archivo remoto. Los usuarios en sistemas clientes
diferentes, pueden acceder al mismo archivo en el sistema NAS.
*Gestión del almacenamiento: con NAS la gestión del almacenamiento está centralizada para un
dispositivo NAS en particular, que puede soportar un amplio número de sistemas de
aplicaciones. La administración del sistema de gestión de NAS es simple y maneja todos los
dispositivos de almacenamiento conectados. Esto provee ventajas de costo al permitir que cada
administrador maneje más capacidad.
Características y ventajas de SAN
Las SANs determinan una mejora del desempeño en la trasmisión de datos, permitiendo que
las transferencias se realicen de fuente a destino con mínima intervención de los servidores.
Por otra parte, una SAN implementa nuevas arquitecturas de red en las que múltiples usuarios
o estaciones de trabajo, pueden acceder a diferentes tecnologías de almacenamiento
conectadas a una misma red.
*Mejoras en la disponibilidad de aplicación: el almacenamiento es independiente de las

aplicaciones y accesible a través de múltiples caminos para mejor flexibilidad y disponibilidad.
154
Anexos
*Mayor rendimiento de aplicación: el procesamiento de almacenamiento se ha eliminado de los

servidores y se ha trasladado a redes separadas.
*Almacenamiento centralizado y consolidado: gestión más simple, escalabilidad, flexibilidad y

disponibilidad.
*Transferencias de datos y almacenamiento de seguridad para sitios lejanos: copia remota de

datos habilitada para protección contra fallas y ataques maliciosos.
155
Anexos
Anexo K. RF de las soluciones para ofrecer DSaaS
Funcionalidades Pydio [132] SeaFile [131] OwnCloud [130]

Contactos X X (mediante plugin)
Notificaciones X
Apuntes X
Historial X X
Favoritos X X
Calendario X
Operaciones sobre X X X
archivos:
Subir X X X
Descargar X X X
Crear Carpeta X X X
Copiar X X
Mover X X
Borrar X X X
Renombrar X X X
Cambiar permisos a un X X
archivo
Detalles del archivo X X X
Editar/Ver archivo X X (mediante plugin)
Indexar contenido X
Comprimir X
Compartir X X X
Buscar X X X
Operaciones sobre la X X X
cuenta de usuario:
Cambiar contraseña X X X
Cambiar Nombre X X X
Cambiar Avatar X X X
Extras: X X X
Addons X X
Visor de Fotos X X
Reproductor de Videos X
Reproductor de X
Música
Editor de Documentos X
Aplicaciones externas X X X
para sincronizar la
información:
PC: Linux, Windows, X X X
MAC
Mobiles: Android y IOS X X X
Requerimientos de
Hardware:
Para un número de 100 50 150
usuarios
RAM 2 GB 2 GB 16 GB
CPU Dual Core 2Ghz No especificado Dual Core XGhz
156
Anexos
Anexo L. RF de las soluciones para ofrecer Salvas
Características Bácula [142] Amanda Backup [143]

Snapshot X
Backup con encriptación X X
Tipos de backup X x
soportado:
Diferencial X X
Completo X
Incremental x x
Deduplicación X
Integración via S3 X
interface
Vmware plugin X x
Windows plugin X x
Linux Plugin X X
KVM plugin X
Hyper-V plugin X
Mac OS plugin x
SAN plugin X x
Oracle plugin X x
MySQL plugin X x
PostgreSQL plugin X
Backup programado X x
Iniciar, parar y reiniciar X
backups
Formato de backup x x
“Open Format”
Soporta múltiples x x
backups
Auto backup en caso de X
no definirse uno
Capacidades de X
verificación de
integridad
Reportes X x
Interfaz web amigable X X
Suporte 10 000 X
servidores
Integración con X
OpenLDAP y Active
Directory
Compresion de datos X X
Requerimientos de
Hardware:
RAM 4 GB 4 GB
CPU 64-bit AMD64/Intel CPU quad-core server-class
CPU
157
Anexos
Anexo M. RF de Ceph y GlusterFS.
CEPH GLUSTERFS
Soporte a SO: Soporte a SO:
CentOS CentOS
Debian Debian
RHEL RHEL
Ubuntu Ubuntu
Fedora Fedora
Arch Linux
Requerimientos de HW: Requerimientos de HW:
1 GB por TB de OSD 2GB de RAM
Micro Dual Core Micro Dual Core o superior
2 interfaces de red mínimo a 1Gbps 1 interfaces de red mínimo a
1Gbps
Interfaces de usuario: Interfaces de usuario:
CLI CLI
**Próximamente KRAKEN soporte para GUI GLUSTER FS GUI plugin
TIPO DE ALMACENAMIENTO SOPORTADO OPERACIONES
Objetos Bloques Ficheros Crear volumen
Características Características Características Expandir volumen
generales: generales: generales:
Interface RESRful Soporte para Thin Soporte para Rebalancear volúmenes
Provisioning semánticas
POSIX
APIS para S3 y Swift Soporte para Metadatos Parar volúmenes
imágnes de hasta 16 separados de
exabytes c/u los datos
Gestión de usuarios Cacheo en memoria Rebalanceo Borrar volúmenes
dinámico
Estadísticas de uso Snapshot Snapshot a Configurar auto-reparación
subdirectorios
Integración a Clon en caliente Soporte para Creación de cuotas
productos de nube FUSE
Despliegue multi- Soporte para Despliegue Creación de servidor Gluster NFS
sitio KVM/libvirt compatible con
Recuperación ante Integración a NFS/CIFS Creación de servidor Gluster
desastres productos de nube SAMBA
Creación de servidor Gluster ZFS
Backup incremental Configuración de Geo-
replicación
Recuperación ante Configuración de gluster-swift
desastres para soporte de objetos y
metadatos
OPERACIONES BASICAS DE CADA UNO Creación de Snapshot a
volúmenes
Operaciones con Operaciones sobre Operaciones Monitoreo de funcionalidades
Regiones bloques con metadatos
Operaciones con Operaciones de Establecimiento Creación de lista de control de
diferentes zonas Snapshot de cuotas acceso
Operaciones sobre Operaciones de Creación de perfil para uso
usuarios Espejo específico de CPU y RAM
Gestión de cuotas Operaciones sobre
QEMU/libvirt
Estadísticas de uso Cacheo
OPERACIONES EN MODO CLUSTER
Operaciones básicas sobre el clúster (creación, eliminación.
Modificación de parámetros)
Monitoreo OSD y PGs
Gestión de Usuarios
Operaciones sobre Pools de datos
158
Anexos
Gestión y configuración de la caché

Configuración de los “Placement Groups” (PG)
Modificación del algoritmo CRUSH
Operaciones sobre los monitores
Creación de perfil para uso específico de CPU y RAM
Configuración del factor de redundancia
159
Anexos
Anexo N. Ejemplos de diseños lógicos
SAN-Ceph
Salvas-Bácula
160
Anexos
DSaaS--Pydio
161
Anexos
Anexo Ñ. Áreas de la Gestión
162
Anexos
Anexo O. Guía de despliegue de Ceph en el CD CUJAE.
Requisitos previos
Con el fin de facilitar la instalación y posterior configuración de CEPH ya sea local o

remotamente empleando una conexión SSH fue necesario realizar varias tareas en cada uno de
los nodos. Además, se hace necesario instalar algunos paquetes adicionales para el uso de Vlans
o bondings.
Instalación y configuración de Ubuntu 16.04 LTS
En el caso particular de la CUJAE se empleó una imagen de Ubuntu 16.04 LTS en su versión
estable sin interfaz gráfica. El nombre de usuario de los nodos es ceph y el hostname
denominado para cada uno fue: ceph01 hasta ceph05 respectivamente.
Finalizado el proceso de instalación se seleccionó de los repositorios el paquete “openssh-

server” con el objetivo de instalar el servidor SSH, el cual permitió la conexión a cada uno de los
nodos desde ubicaciones remotas en la red.
La distribución de las particiones en el disco del Sistema Operativo es:
 Una para el swap cuyo tamaño debe ser del doble de la capacidad de RAM. Esta partición
se debe especificar que es swap.
 Una de 40 GB con File System (ext4, xfs o btrfs). A esta partición no se le activa la
opción /boot flag pero si se le fija el punto de montaje “/”.
La instalación del paquete “openssh-server” no es obligatorio que se efectúe durante la

instalación del sistema, esto puede realizarse también una vez culminada la instalación.
Nota: Todos los comandos que se ejecuten se recomienda que sean bajo la cuenta de root
Para configurar los repositorios se editó el fichero sources.list ejecutando
# nano /etc/apt/sources.list
Una vez dentro del fichero se eliminaron (se comentó) las líneas existentes
y se agregaron otras con el propósito de utilizar los repositorios de Debian 8, Ceph y Zabbix
(posterior monitoreo) internos de la CUJAE:
deb http://10.8.11.4/ubuntu xenial-backports main universe restricted multiverse
163
Anexos
deb http://10.8.11.4/ubuntu xenial main universe restricted multiverse

deb http://10.8.11.4/ppa/ceph/jewel xenial main
deb http://10.8.11.4/ppa/zabbix/3.2/ubuntu/ xenial main contrib non-free
A continuación, guardamos los cambios y ejecutamos:
# apt-get update
También se instalaron los paquetes ifenslave vlan y bridge-utils necesarios para configurar la
red como se mostrará más adelante.
# apt-get install ifenslave vlan bridge-utils
Configuración de la interfaz de red
Los nodos cuentan con dos redes, una pública para atender las peticiones de los clientes y otra
privada para las operaciones internas del clúster específicamente para las operaciones de
replicación de la información y recuperación ante fallos.
La red pública es la 10.8.9.0 y la del clúster 192.168.0.0 y se establecieron VLANs para separar
el tráfico de la red pública de la del clúster 702 y 4002 respectivamente.
Además, se aplicaron troncales LACP a la red cliente para aumentar su ancho de banda a 2Gbps.
Para poder emplear la configuración de red bajo vlans se requiere de instalar los paquetes
“bridge-utils” e “ifenslave” ya previamente informado.
Para configurar la red se ejecuta:
# nano /etc/network/interfaces
El fichero interface quedó como se muestra en la siguiente figura:
164
Anexos
Es necesario editar el fichero hosts en todos los nodos para facilitar los procedimientos
posteriores. Esto se hace ejecutando en cada uno:
# nano /etc/hosts
Una vez dentro agregamos los hostnames con la dirección IP de todos los nodos. A continuación,
vemos como queda el fichero en el nodo 1, análogamente debe quedar en los demás:
165
Anexos
Configurar el acceso por medio de SSH.
Primeramente, se instala SSH en cada nodo. Para ello ejecutamos:
# apt-get install ssh
A continuación, nos dirigimos al fichero sshd_config para modificar una línea de configuración.
Es necesario su modificación para que SSH pueda loguearse como root en los demás nodos.
Para ello modificamos ese fichero en la línea donde dice “PermitRootLogin” borramos lo que
está y ponemos “yes”.
Para realizar lo anterior ejecutamos:
# nano /etc/ssh/sshd_config
Así debería quedar:
Después guardamos los cambios y reiniciamos el servicio SSH
# service ssh restart
Para utilizar el servicio ssh la sintaxis es: ssh username@(remote_IP or hostname)
Despliegue del clúster Ceph
Primeramente, se requiere de instalar los paquetes de CEPH en los nodos de almacenamiento.

Existen varias maneras de hacerlo a través de internet. En la CUJAE existe una copia de los
repositorios de la última versión estable hasta la fecha (Jewel 10.2.5), por lo que resulta sencillo
instalar los paquetes configurando el fichero sources.list ya realizdo inicialmente.
Para instalar los paquetes de Ceph se autentica remotamente vía SSH en cada nodo y se ejecuta:
# apt-get install ceph
Existen dos formas de desplegar CEPH. La más usada es mediante el paquete “ceph-deploy”, el
cual simplifica bastante el proceso realizando en pocas operaciones la instalación y el despliegue
de los diferentes componentes del sistema en todos los nodos desde el admin-node.
166
Anexos
La otra forma de despliegue es totalmente manual, lo que es más trabajoso y requiere un poco
más de conocimiento en sistemas Linux. En esta guía se describirá el proceso manual debido a
la ausencia del paquete “ceph-deploy” en los repositorios locales de CEPH.
Desplegando el primer monitor
Un clúster de almacenamiento de Ceph requiere como mínimo un monitor para operar. Sin
embargo, siempre es recomendable utilizar más de un monitor y de preferencia un número
impar de ellos para garantizar quorum entre los mismos.
1- (OPCIONAL, si usted no se encuentra frente a los servidores).

Autenticarse en el nodo 1 como superusuario mediante ssh.
# ssh username@hostname
Nota: Si no se tiene editado el fichero /etc/hosts hay que utilizar la dirección IP del nodo.
2- Generar el FSID del clúster, este será el identificador del clúster. Este identificador es
único para cada clúster.
Para ello debemos instalar el paquete uuid-runtime
# apt-get install uuid-runtime
Generar el FSID:
# uuidgen
3- Copiar el fsid del clúster ya que va a ser necesario su uso posterior
4- Configurar el fichero del clúster “ceph.conf” con los principales parámetros. Utilizar la
salida del comando anterior para fijar el parámetro FSID en el fichero.
# nano /etc/ceph/ceph.conf
Existen diversas maneras de configurar el fichero “ceph.conf” (ver documentación oficial
en el sitio web), a continuación se muestra como se configuró en el CPD CUJAE.
Nota: Recuerde que el fsid generado será diferente al de la figura puesto que son
identificadores únicos para cada clúster.
167
Anexos
Nota: a partir de ahora los comandos serán un poco largos por lo que en la realización de esta
guía ocupan dos renglones del documento. Es necesario aclarar que son comandos únicos, es
decir a la hora de escribirlos son de una única línea. También es necesario aclarar que donde
dice “ allow “ se usa comilla simple “ ‘ “ por eso se recomienda cambiar el teclado a Inglés y no
copiar y pegar sino escribirlos detenidamente y sin equivocaciones ya que de no ser así se
pueden generar configuraciones erróneas.
5- Crear un fichero “keyring” para el monitor y generar una llave secreta con los
permisos correspondientes.
# ceph-authtool --create-keyring /tmp/ceph.mon.keyring --gen-key -n mon. --cap mon ‘allow *’
6- Crear el usuario admin con permisos de administrador y añadirlo al fichero keyring.
# ceph-authtool --create-keyring /etc/ceph/ceph.client.admin.keyring --gen-key -n client.admin --set-

uid=0 --cap mon ‘allow *’ --cap osd ‘allow *’ --cap mds ‘allow *’
7- Añadir la llave del usuario “admin” al fichero “ceph.mon.keyring”.
# ceph-authtool /tmp/ceph.mon.keyring --import-keyring /etc/ceph/ceph.client.admin.keyring
8- Generar el mapa del monitor.
# monmaptool --create --add ceph01 10.8.9.141 --fsid (fsid del clúster) /tmp/monmap
168
Anexos
9- Crear directorios para el monitor
# mkdir /var/lib/ceph/mon/ceph-ceph-ceph01
10- Generar el demonio del monitor.
# ceph-mon --mkfs -i ceph01 --monmap /tmp/monmap --keyring /tmp/ceph.mon.keyring
11- Iniciar el servicio del monitor.
# service ceph -a start mon.ceph01
12- Para el servicio del monitor.
#service ceph -a stop mon.ceph01
13- Dar permisos a Ceph para escribir en la carpeta del monitor
# chown ceph:ceph /var/lib/ceph/mon/ceph-ceph-ceph01
14- Iniciar nuevamente el servicio (paso 11)
15- Revisar el estado del clúster para comprobar la creación del monitor.
# ceph –s
Nota: Fijarse en el parámetro “monmap”. Si la operación fue exitosa deberá decir que hay un
monitor creado y dará el hostname y la dirección IP del mismo. El parámetro “health”
momentáneamente pondrá error. No preocuparse por esto ya que todavía faltan componentes
por agregar.
Desplegando los primeros OSD
Una vez que se ha desplegado el primer monitor es hora de añadir los primeros OSD al clúster.
Se comienza creando un OSD por cada HDD presente en el nodo donde se creó el primer
monitor, momentáneamente no se crea ningún OSD en el HDD donde está instalado el Sistema
Operativo ya que no es recomendable según la documentación oficial.
169
Anexos
1- Verificar que se encuentra en el nodo 1, o sea, donde se creó el primer monitor.

2- Revisar los discos disponibles en el nodo. En el caso de los nodos de almacenamiento
del centro de datos cada uno posee 4 discos, uno destinado al SO y los otros 3 para
almacenamiento.
Ejecutamos
# lsblk
Nota: Para una mayor comprensión se supondrá que los discos dedicados al almacenamiento
serán sdb, sdc y sdd respectivamente. No obstante, el administrador que realice esta operación
debe tener presente cuando ejecute este comando cuales son los discos donde quiere crear los
OSD. No tiene por qué coincidir con esta guía. ¡CUIDADO CON EL DISCO DEL SISTEMA
OPERATIVO!
3- Los OSD trabajan con la tabla de partición GUID (GPT), por lo que es necesario cambiar
la etiqueta a GPT.
# parted /dev/sdb mklabel GPT
# parted /dev/sdc mklabel GPT
# parted /dev/sdd mklabel GPT
4- Preparar los OSD con el FSID del clúster y la información del sistema de ficheros a
emplear.
# ceph-disk prepare --cluster ceph --cluster-uuid (fsuid del cluster) –fs-type xfs /dev/sdb
# ceph-disk prepare --cluster ceph --cluster-uuid (fsuid del cluster) –fs-type xfs /dev/sdc
# ceph-disk prepare --cluster ceph --cluster-uuid (fsuid del cluster) –fs-type xfs /dev/sdd
Nota: Se escogió como sistema de ficheros “xfs” por recomendación en la documentación

oficial, no obstante, puede escogerse además “ext4” y “btrfs”.
5- Finalmente activar los OSD previamente configurados.
# ceph-disk activate /dev/sdb1
# ceph-disk activate /dev/sdc1
170
Anexos
# ceph-disk activate /dev/sdd1
6- Revisar nuevamente el estado del clúster para visualizar los OSD agregados.
# ceph -s
Nota: Si las operaciones realizadas fueron correctas deberán aparecer en la salida del comando
tres OSD, el estado “up” significa que el servicio está funcionando.
7- Copiar los ficheros “ceph.conf” y “ceph.client.admin.keyring” desde el nodo 1 hacia los

demás nodos que componen el clúster.
ceph.conf:
# scp /etc/ceph/ceph.conf ceph02:/etc/ceph
ceph.client.admin.keyring:
# scp /etc/ceph/ceph.client.admin.keyring ceph02:/etc/ceph
Nota: Si el comando no funciona se recomienda revisar los permisos de los usuarios y revisar las
configuraciones de SSH.
8- Si después de copiar correctamente los ficheros anteriores los nodos no pueden

conectarse al clúster revisar las reglas de filtrado de los respectivos firewalls.
171
Anexos
Escalando el clúster
Una de las características más atractivas de CEPH es su sencilla escalabilidad. Como

administrador es necesario saber cómo agregar o retirar componentes del clúster. Estas
operaciones se pueden realizar de forma online y no requieren en ningún momento la
detención del mismo. A continuación, se añadirán dos monitores y nueve OSD al sistema de
almacenamiento.
Añadiendo Monitores

2- Crear los directorios para el nuevo monitor
# mkdir -p /var/lib/ceph/mon/ceph-ceph02 /tmp/ceph02
3- Extraer la información de la llave del clúster.
# ceph auth get mon. -o /tmp/ceph02/monkeyring
4- Recuperar el mapa del monitor del clúster.
# ceph mon getmap -o /tmp/ceph02/monmap
5- Construir el nuevo monitor usando la llave y el mapa de monitor existente.
# ceph-mon -i ceph02 --mkfs --monmap /tmp/ceph02/monmap –keyring /tmp/ceph02/monkeyring
6- Agregar el nuevo monitor al clúster.
# ceph mon add ceph02 10.8.9.142:6789
7- Iniciar el servicio del monitor
# service ceph -a start mon.ceph02
172
Anexos
8- Para el servicio del monitor.
#service ceph -a stop mon.ceph02
9- Dar permisos a Ceph para escribir en la carpeta del monitor
# chown ceph:ceph /var/lib/ceph/mon/ceph-ceph-ceph02
10- Iniciar nuevamente el servicio (paso 7)
11- Una vez que el monitor ha sido agregado se comprueba el estado de ceph.
# ceph –s
Nota: Deberá decir ahora que se encuentran dos monitores.
12- Repita los mismos pasos para añadir el tercer monitor en el nodo 3 (ceph03). Una
vez añadido el tercer monitor en el estado del clúster deberán aparecer los tres
monitores.
Nota: Tenga en cuenta ahora el nombre y la dirección IP del monitor (ceph03 y 10.8.9.143)
Añadiendo OSD

2- Revisar los discos disponibles en el nodo. En el caso de los nodos de almacenamiento

del centro de datos cada uno posee 4 discos, uno destinado al SO y los otros 3 para
almacenamiento.
Ejecutamos
# lsblk
Nota: Para una mayor comprensión se supondrá que los discos dedicados al almacenamiento
serán sdb, sdc y sdd respectivamente. No obstante, el administrador que realice esta operación
debe tener presente cuando ejecute este comando cuales son los discos donde quiere crear los
OSD. No tiene por qué coincidir con esta guía. ¡CUIDADO CON EL DISCO DEL SISTEMA
OPERATIVO!
173
Anexos
3- Los OSD trabajan con la tabla de partición GUID (GPT), por lo que es necesario
cambiar la etiqueta a GPT.
# parted /dev/sdb mklabel GPT
# parted /dev/sdc mklabel GPT
# parted /dev/sdd mklabel GPT
4- Preparar los OSD con el FSID del clúster y la información del sistema de ficheros a
emplear.
# ceph-disk prepare --cluster ceph --cluster-uuid (fsuid del cluster) –fs-type xfs /dev/sdb
# ceph-disk prepare --cluster ceph --cluster-uuid (fsuid del cluster) –fs-type xfs /dev/sdc
# ceph-disk prepare --cluster ceph --cluster-uuid (fsuid del cluster) –fs-type xfs /dev/sdd
Nota: Se escogió como sistema de ficheros “xfs” por recomendación en la documentación

oficial, no obstante, puede escogerse además “ext4” y “btrfs”.
5- Finalmente activar los OSD previamente configurados.
# ceph-disk activate /dev/sdb1
# ceph-disk activate /dev/sdc1
# ceph-disk activate /dev/sdd1
6- Revisar nuevamente el estado del clúster para visualizar los OSD agregados.
# ceph -s
Nota: Ahora deberá aparecer que hay 6 OSDs
7- Repita los mismos pasos para agregar osd en el nodo 3, 4 y 5 (ceph03, ceph04 y
ceph05).
Nota: En el caso de los nodos que no tienen monitores como el nodo 4 antes de ejecutar el paso
5 es necesario realizar lo siguiente:
Entrar en el nodo 1 y copiar el siguiente fichero al nodo 4 (o los nodos que no tienen monitores)
174
Anexos
# scp /var/lib/ceph/bootstrap-osd/ceph.keyring ceph02:/var/lib/ceph/bootstrap-osd/
Finalmente continuar con el paso 5.
Instalación y configuración de NTP
Es muy probable que en el estado del clúster se encuentre la notificación “clock skew warning”,
esto significa que no está configurado el Protocolo de Tiempo de Red (NTP) por lo que los
monitores están desincronizados. Esto atenta contra el funcionamiento del clúster ya que la
mayoría de las operaciones realizadas por este requieren estar sincronizadas a un servidor de
tiempo común en la red. En caso de no existir uno es necesario crearlo. En el centro de datos
de la CUJAE existe un servidor NTP con direccion IP 10.8.9.24

Autenticarse en todos los como superusuario mediante ssh.
2- Instalar los paquetes “ntp”, “ntp-doc” y “ntpstat”.
# apt-get install ntp ntp-doc ntpstat
3- Configurar el fichero “ntp.conf”.
# nano /etc/ntp.conf
4- Dentro del fichero se eliminan (se comentan) los servidores que vienen por default
y se agrega el server de la CUJAE. Debe quedar así:
5- Guardar el fichero y reiniciar el servicio ntp.
# service ntp restart
175
Anexos
6- Revisar a que servidor de los añadidos esta sincronizado el nodo.
# ntpq –pn
Nota: El asterisco indica a que servidor esta sincronizado.
7- Después de realizar este proceso en todos los nodos esperar unos segundos y
ejecutar:
# ceph –s
Nota: Debería decir “HEALTH_OK” en caso de que no lo diga esperar unos segundos más.
176
Anexos
177
View publication stats

Tesis Art

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Tesis Art

Uploaded by

Copyright:

Available Formats

See discussions, stats, and author profiles for this publication at: https://www.researchgate.

PROCEDIMIENTO DE DISEÑO DE SISTEMAS DE ALMACENAMIENTO PARA

Thesis · January 2017

Arturo Díaz Crespo

The user has requested enhancement of the downloaded file.

PROCEDIMIENTO DE DISEÑO DE SISTEMAS DE

Arturo N. Díaz Crespo

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 teoría es cuando uno sabe todo y nada funciona,

la práctica es cuando todo funciona y nadie sabe por qué”

el autor presentado en la declaración, el cual avala su originalidad y declara que no ha sido

con fines educativos o informativos por el Departamento de Telecomunicaciones y Telemática

de la Universidad Tecnológica de La Habana.

Firma del autor

Certificamos que el presente trabajo fue desarrollado por ______________bajo nuestra

MSc. Lilia Rosa García Perellada Dr. Alain A. Garófalo Hernández

Por tanto, en el presente trabajo se confecciona un método para diseñar Sistemas de

FRASE ..................................................................................................................................... III

DECLARACIÓN DE AUTORÍA .................................................................................................. VI

RESUMEN ............................................................................................................................. VII

ABSTRACT ............................................................................................................................ VIII

INDICE DE FIGURAS .............................................................................................................. XII

INDICE DE TABLAS ............................................................................................................... XIII

Capítulo 1: “Procedimientos de diseño de sistemas de almacenamiento. Elementos

Anexo A. Comparativa de los métodos de diseños de sistemas de almacenamiento para

Tabla 1 Referencias consultadas en la evaluación de los métodos de diseño. ..................... 9

El no tener un procedimiento para el diseño de estos sistemas puede traer numerosos

Dada la situación problemática anterior el problema a resolver es: la insuficiente articulación

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,

 Comparar los principales modelos de referencia de SA proporcionados por la Unión

 Seleccionar el modelo de referencia para el SA a emplear en el procedimiento a obtener.

 Validar el procedimiento obtenido.

- Métodos teóricos. Mediante una revisión bibliográfica se podrá conocer las

- Métodos empíricos se utilizaron para el análisis documental durante la revisión

- 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

El trabajo de diploma se dividió en introducción, tres capítulos, conclusiones, recomendaciones,

Capítulo 1: “Procedimientos de diseño de sistemas de almacenamiento. Elementos considerados

Capítulo 3: “Validación del método de diseño de Sistemas de Almacenamiento para Centros de

Capítulo 1: “Procedimientos de diseño de sistemas de almacenamiento. Elementos considerados

El autor de la presente investigación no identificó un procedimiento de diseño de SA para CD

1.2. Filosofía de diseño top-down. Aplicación al diseño de sistemas de almacenamiento

disponibilidad, adaptabilidad, flexibilidad y escalabilidad. Esta particularidad debe ser aplicada

FASE I, análisis de los requerimientos:

 En caso de ser necesario, si ya existiese una infraestructura desplegada, determinar y

FASE II, diseño lógico:

 Identificar los tipos de sistemas de almacenamiento a utilizar: Redes de Área de

FASE III, diseño físico:

 Desarrollar el proceso de selección de la solución de SA que se acople a las

FASE IV, probar, optimizar y documentar:

 Despliegue de un prototipo del diseño propuesto, o su modelación, con las

1.3. Evaluación de los métodos de diseños de sistemas de almacenamiento para centros de

Gestores de Nubes SLCA

Figura 2 Referencias consultadas en la evaluación de los métodos de diseño

Resultados obtenidos en la búsqueda:

De las publicaciones Académicas se pudieron identificar tres correspondiente al tema en