METODOLOGÍA PARA EL DIMENSIONAMIENTO DE LOS

RECURSOS DE CÓMPUTO PARA PYME SOBRE NUBE PRIVADA

METHODOLOGY FOR SIZING COMPUTE RESOURCES FOR SME

OVER PRIVATE CLOUD
Daniel Clavijo Coca1, Dennys R. Moreno Véliz2, Lilia R. García Perellada3, Sergio J. Vega Gutiérrez4,
José M. de la Fé Herrero5, Alain A. Garófalo Gutiérrez6

1 Universidad Tecnológica de la Habana, Cuba, dann1telecom@gmail.com, 19 #952 /8 y 10, Plaza de la Revolución

2 Universidad Tecnológica de la Habana, Cuba, droly05@gmail.com
3 Universidad Tecnológica de la Habana, Cuba, liliarosag@gmail.com
4 Universidad Tecnológica de la Habana, Cuba, sergiojvg92@gmail.com
5 Universidad Tecnológica de la Habana, Cuba, jmdelafe92@gmail.com
6 Universidad Tecnológica de la Habana, Cuba, aagarofal@gmail.com

RESUMEN: Las nubes privadas deben ser diseñadas partiendo del estudio de los objetivos del negocio, sus
restricciones y requerimientos técnicos. El diseño de los recursos de cómputo y la selección del gestor de nube
deben heredar el enfoque del diseño desde la perspectiva del negocio. Sin embargo, en la bibliografía del mundo
académico e industrial referente a ambos procesos fue identificado que de manera general la perspectiva del
negocio no es adoptada, y que no se brindan métodos que abarquen pasos sistemáticos y estructurados para:
dimensionar en función de los servicios a soportar, seleccionar la plataforma de virtualización, los tipos de servi-
dores y el gestor de la nube privada. Las insuficiencias identificadas pueden impactar negativamente en el desem-
peño, la disponibilidad, la adaptabilidad, la usabilidad y la factibilidad económica del proyecto obtenido, por lo que
el presente trabajo propone procedimientos para el diseño de los recursos de cómputo y la selección de gestores
de nubes para nubes privadas con soporte para infraestructura como servicio para pequeñas y medianas empre-
sas. Los resultados alcanzados aportan al diseño de infraestructuras de nubes privadas basadas en hardware de
propósito general y software libre y código abierto, dotándoles de un enfoque de diseño desde la perspectiva del
negocio, impactando positivamente en las inversiones de capital y de operaciones del centro de datos, así como
en la independencia tecnológica. Se emplearon métodos analíticos, sistemáticos y empíricos para el desarrollo
de la investigación.

Palabras Clave: computación en la nube, dimensionamiento, PyME, virtualización, servidores

ABSTRACT: Private clouds should be designed based on the study of business objectives, their restrictions and
technical requirements. The design of computing resources and the selection of the cloud manager must inherit
the design approach from the business perspective. However, in the academic and industrial world bibliography
referring to both processes, it was identified that in general the business perspective is not adopted, and that there
“VIII Simposio de Telecomunicaciones”
 Clavijo, D.; Moreno, D R., García, LR. | “METODOLOGÍA PARA EL DIMENSIONAMIENTO DE LOS RECURSOS DE CÓMPUTO PARA PYME SOBRE NUBE
PRIVADA”

are no provided methods covering systematic and structured steps to: dimension according to the services to
support, select the virtualization platform, the types of servers and the private cloud manager. The identified short-
comings can negatively impact the performance, availability, adaptability, usability and economic feasibility of the
project obtained, so this work proposes procedures for the design of computing resources and the selection of
cloud managers for private clouds with support for infrastructure as a service for small and medium enterprises.
The results achieved contribute to private cloud infrastructures design based on general purpose hardware and
open source free software, giving them a design approach from the business perspective, positively impacting
capital investments and data center operations, as well as in technological independence. Analytical, systematic
and empirical methods were used for the development of the research.

Keywords: cloud computing, sizing, SME, virtualization, servers,

1. INTRODUCCIÓN generarán las aplicaciones que se soportarán [2],

La Computación en la Nube (CN) es un para-
digma de gestión de recursos de cómputo como al-
macenamiento, red, aplicaciones, servicios y servi-
dores, que a través de una conexión por Banda An-
cha (BA), permite rápido aprovisionamiento y libera-
ción bajo demanda de recursos, con altos índices de
escalabilidad, requiriendo un mínimo de esfuerzos
por parte de los usuarios finales y los proveedores.
Las empresas pueden adoptar este modelo de ma-
nejo de servicios de Tecnologías de Información (TI)
para abaratar costos de gestión y mantenimientos
del Centro de Datos (CD). Tres bloques funcionales
de la nube lo constituyen la plataforma de virtualiza-
ción, los nodos de cómputo y la Plataforma de Ges-
tión de Nube (CMP 1).
En el caso de las plataformas de virtualización y
de la CMP no fueron identificados mecanismos que
permitiesen realizar su selección tomando en cuenta
las necesidades del cliente. Las tendencias hoy en
la selección son: elegir la solución en base al lide-
razgo en el mercado, el pago de licencias o no, y los
criterios de los proveedores de soluciones, los cua-
les defienden a cabalidad sus productos [1]. No fue-
ron identificados mecanismos que permitiesen se-
leccionar plataformas de virtualización, así como
CMP.
En el diseño de los nodos de cómputo diversas
fuentes consultadas hacen referencia a la necesidad
de partir el proceso desde el análisis de la carga que
pero no fueron identificados instrumentos para ello,
y la tendencia es sobredimensionar para garantizar
la Calidad de Servicio (QoS 2).
Por ello el presente trabajo tuvo como objetivos
proponer un método de dimensionamiento de los re-
cursos de cómputo para Pequeñas y Medianas Em-
presas (PyME), el cual abarca la selección de: la pla-
taforma de virtualización, la CMP y los servidores de
cómputo. Los resultados alcanzados fueron un mé-
todo de diseño del bloque funcional de recursos de
cómputo de una NP, que parte de los requerimientos
técnicos y restricciones de la PyME, así como de la
caracterización de los servicios a soportar. Toda la
propuesta fue sustentada sobre Software Libre y Có-
digo Abierto (SLCA) y hardware de propósito gene-
ral.
2. TRABAJO PREVIO
La filosofía de diseño de redes top-down consi-
dera como parte de su primera fase la identificación
y caracterización de las aplicaciones que soportará
el sistema a diseñar. Plantea que el diseño debe par-
tir de las aplicaciones por lo que la infraestructura
subyacente debe tributar a sus requerimientos.
En el ámbito del diseño de Nubes Privadas (NP)
la comunidad científica se ha manifestado ante la ne-
cesidad de tomar en cuenta la carga de trabajo, los
requerimientos y Indicadores de Desempeño Claves
(KPI 3) de las aplicaciones para el dimensionamiento
de los recursos virtuales que las soportan, y a su vez

1Siglas correspondientes al término en inglés: Cloud of Service.

Management Platform 3 Siglas correspondientes al término en inglés: Key

2 Siglas correspondientes al término en inglés: Quality Performance Indicators

“VIII Simposio de Telecomunicaciones”
 Clavijo, D.; Moreno, D R., García, LR | “METODOLOGÍA PARA EL DIMENSIONAMIENTO DE LOS RECURSOS DE CÓMPUTO PARA PYME SOBRE NUBE
PRIVADA”

para su localización en los recursos físicos subya-
centes. Se plantea que deben ser analizadas la na-
turaleza y estructura de las aplicaciones para cono-
cer cómo estas pueden explotar al máximo las bon-
dades de la nube [3]. No obstante, pocas son las so-
luciones de proveedores que las toman en cuenta a
la hora de dimensionar los recursos de cómputo [4].
2.1. Tendencias en la selección de hiper-
visores
La Figura 1 se corresponde con el cuadrante má-
gico de los principales proveedores de soluciones de
virtualización propietarias en agosto de 2016.
VMWare vCloud KVM, VMWare ESXi y Hyper-V
Proxmox KVM y LXC
Los principales criterios identificados en la selec-
ción de plataformas de virtualización fueron: desem-
peño, compatibilidad de hardware, usabilidad, alta
disponibilidad, confiabilidad, herramientas de ges-
tión, licencias y costos, escalabilidad, familiaridad
con el software, madurez, seguridad, tiempo de
aprovisionamiento, Máximos CPU5 Virtual (vCPU) y
RAM 6por Máquina Virtual (MV), y Máximos vCPU y
RAM por anfitrión.
Las principales variables de elección de un CMP
son las recomendaciones realizadas por terceros, la
seguridad y la familiaridad/experiencia con la tecno-
logía. KVM es el hipervisor por defecto en soluciones
como OpenNebula, OpenStack y Proxmox. VMWare
ESXi es la solución que mejor desempeño tiene en
general, pero tiene altas restricciones en cuanto a li-
cencias y costos, y requisitos de hardware más es-
trictos. LXC aun teniendo altos índices de desem-
peño, ideal para Computación de Alto Rendimiento
(HPC 7), no tiene la madurez tecnológica de las otras
soluciones, y es menos flexible en cuanto a Sistemas
Operativos (SO) huéspedes que puede virtualizar.

2.2. Tendencias en la selección de nodos

de cómputo
Actualmente los parámetros que se toman en
cuenta en la selección de los servidores son: el tipo
de servidor, el desempeño, la eficiencia, las dimen-
siones del espacio que va a ocupar, estándares,
Figura 1 Cuadrante mágico de Gartner sobre vir- como la Asociación de la Industria de las Telecomu-
tualización x86 nicaciones(TIA 8). En la actualidad existen productos
La Tabla 1 presenta las principales soluciones de en el mercado denominados Comercial-Of-The-Shell
plataforma de NP del mercado y el soporte que estas (COTS), productos que no son fabricados para una
brindan a los hipervisores. función específica, ni que están sujetos a un soft-
ware propietario en particular.
Tabla 1 Soporte de plataformas de NP a hiperviso-
res Durante el proceso de selección de los servido-
res, es necesario detenerse en el análisis de los
Proveedor de
IaaS 4
Hipervisor COTS y tener en cuenta aquel hardware heredado
que las empresas presentan. El hardware heredado
Apache CloudStack Xen, KVM, Hyper-V y VMWare
tiene la ventaja que es útil mientras continúe su fun-
Eucalyptus Xen y KVM
cionamiento, algo que las empresas tienden a tener
Microsoft Private en cuenta, sin embargo, su actualización y soporte
Hyper-V, Xen y VMWare
Cloud
por parte del proveedor puede estar eliminada en el
OpenNebula Xen, KVM, VMWare, LXC y LXD mercado.
KVM, Xen, VMWare, Virtuozzo, Ironic,
OpenStack
LXC, LXD Hoy día los servidores tipo tower son muy poco

4 Siglas correspondientes al término en inglés: Infras- Access Memory

7 Siglas correspondientes al término en inglés: High
tructure as a Service
5 Siglas correspondientes al término en inglés: Central Performance Computing
8 Siglas correspondientes al termino en inglés: Teleco-
Processing Unit
6 Siglas correspondientes al término en inglés: Random munications Industry Associations
“VIII Simposio de Telecomunicaciones”
 Clavijo, D.; Moreno, D R., García, LR | “METODOLOGÍA PARA EL DIMENSIONAMIENTO DE LOS RECURSOS DE CÓMPUTO PARA PYME SOBRE NUBE
PRIVADA”

empleados para el diseño de CD producto de que
ocupan mucho espacio y no presentan igual desem-
peño y eficiencia que los servidores tipo blade y tipo
rack, por otra parte, durante las investigaciones rea-
lizadas se pudo notar proveedores de hardware,
como INSPUR y Huawei, que en sus sitios web de
negocios no reflejan una tendencia a brindar este
tipo de servidores como solución tanto como lo ha-
cen con los servidores Rack y Blade [7], [8], por otro
lado proveedores como HPE continúan brindando
estas soluciones [9].
futuras se consultarán las sugerencias y/o indicacio-
nes del ecosistema entorno a la aplicación en cuanto
a su dimensionamiento.
Se debe monitorear los KPI promedio y máximo
diariamente durante al menos un mes en el horario
laboral de la entidad. Para hallar el KPI máximo se
debe aplicar el 90 percentil al conjunto de muestras
analizadas para descartar un 10% de resultados po-
tencialmente anómalos. Las métricas de las tablas
se completan calculando el promedio de los valores
obtenidos diariamente.

2.3. Tendencias en la selección de CMP 3.1. Datos Generales

La Figura 2 contiene las estadísticas de Google La Tabla 3 recoge datos generales comunes para
Trends. Puede observarse que OpenStack tiene am- todas las aplicaciones. Se debe llenar con personal
plia preferencia, y luego, con notable diferencia so- de la entidad que posea conocimientos de los servi-
bre CloudStack y OpenNebula está Proxmox. cios telemáticos en producción.
OpenStack es ampliamente la CMP más popular.
Esto se debe a sus múltiples formas de despliegue, Tabla 2 Identificación de aplicaciones de usuarios
y de servicios
soporte monetario, una enorme comunidad de desa-
rrolladores, la inmensa cantidad de Requerimientos
Funcionales (RF) que posee respecto a la compe-
tencia y la adopción por parte de compañías podero-
sas como AT & T, Yahoo! , Rackspace, National Ae-
ronautics and Space Administration (NASA), el Con-
seil Européen pour la Recherche Nucléaire (CERN), Dis-
ney, Cisco, y Huawei.

3.2. Calidad de experiencia y calidad de

servicio
Para evaluar la QoS los autores proponen em-
plear pruebas de carga [10]. La Figura 3 muestra el
escenario típico para correr las diferentes pruebas.
Las MV de los servicios a ser probados deben estar
lo más inactivas posibles para que las métricas sean
fiables. Las pruebas de QoE quedan sugeridas para
realizar, sin embargo, no se muestran, puesto que
no entra dentro del alcance del presente trabajo.
Figura 2 Comparativa de Google Trends entre CMP

3. INSTRUMENTO PARA IDENTIFICAR Y

CARACTERIZAR LAS APLICACIONES Y
SERVICIOS
En dependencia del negocio para el cual se está
diseñando la infraestructura de cómputo es necesa-
rio identificar cuáles son las aplicaciones y los servi-
cios existentes, y los que se proyectan implementar
en un corto y largo plazo no mayor a los cinco años.
Para las aplicaciones existentes se realizarán prue-
bas en producción, mientras que para las nuevas y

“VIII Simposio de Telecomunicaciones”

 Clavijo, D.; Moreno, D R., García, LR | “METODOLOGÍA PARA EL DIMENSIONAMIENTO DE LOS RECURSOS DE CÓMPUTO PARA PYME SOBRE NUBE
PRIVADA”

Figura 3 Escenario de pruebas Carga a virtualizar

Comparar SO
OSLV cumple Virtualizar con LXC/
A las aplicaciones se les evalúa el Troughput y el Hipervisor impuesto? NO
con RF?
SI huésped y
anfitrión
Igual
LXD

tiempo de respuesta según sus KPI particulares, a NO

SI
las MV que contienen la aplicación se les evalúa la Diferente

utilización de acuerdo a la Tabla 4. A partir de la Ta- Tiene los RF?

Virtualizar con KVM Quitar 400M de
RAM si previamente
HVM
bla 4 los administradores deben considerar si es ne- sugerir

cesario cambiar la asignación de recursos virtuales SI

SI
en función del nivel de su explotación. De ocurrir mo- Configurar la
instancia virtual

dificaciones se debe realizar una prueba de QoE con Incompatibilidad

con OSLV
Incrementar recursos/
verificar configuración

la nueva configuración de la MV para analizar si Evaluar

comportamiento
hubo algún impacto negativo en la percepción del NO Problemas Bajo desempeño

servicio por parte de los usuarios. Para dimensionar

Resultados
en función de la cantidad de usuarios futuros de satisfactorios

No virtualizable
forma aproximada es necesario aplicar la Ecuación
1 a cada una de las métricas obtenidas anterior- Identificar causas

mente. Donde Ux representa la utilización.

Figura 4 Proceso de selección de los hiperviso-
res

Debido a las experiencias de los autores, en oca-

siones se requiere de configuración adicional
para que determinadas aplicaciones se ejecuten
correctamente en los contenedores, ej. servidor
NFS y servidor VNC. Se recomienda entonces
antes de migrar de la solución existente a
LXC/LXD hacer una prueba de compatibilidad.

3.3.1. Pruebas para evaluar los RNF de los

hipervisores
Tabla 3 Métricas de utilización por aplicación
En este trabajo se concibió un amplio conjunto de
𝑈𝑈𝑈𝑈 𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎×𝑈𝑈𝑈𝑈𝑈𝑈𝑈𝑈𝑈𝑈𝑈𝑈𝑈𝑈𝑈𝑈 𝑓𝑓𝑓𝑓𝑓𝑓𝑓𝑓𝑓𝑓𝑓𝑓𝑓𝑓 pruebas para caracterizar los Requerimientos no
𝑈𝑈𝑈𝑈 𝑓𝑓𝑓𝑓𝑓𝑓𝑓𝑓𝑓𝑓𝑓𝑓 = (1)
𝑈𝑈𝑈𝑈𝑈𝑈𝑈𝑈𝑈𝑈𝑈𝑈𝑈𝑈𝑈𝑈 𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎 Funcionales (RNF) que caracterizan a los hiperviso-
Si se desea ofrecer IaaS Hay que analizar los re- res. Debido a la longitud del conjunto de pruebas se
querimientos de capacidad de los usuarios finales. presenta solamente una prueba de eficiencia:
Estos se obtienen en forma de encuestas. Si no los
tienen definidos se les sugiere seguir la serie de ins- Objetivo: Medir la densidad de MV de un hipervi-
trumentos expuestos anteriormente, hasta que final- sor. La Tabla 5 muestra las métricas claves que de-
mente lleguen a sus requerimientos de capacidad en finen la eficiencia de utilización de RAM en un hiper-
términos de números concretos en vCPU, RAM, Al- visor.
macenamiento, Capacidad y Throughput, y Ancho Tabla 4 Métricas de eficiencia en hipervisores
de Banda.
Métrica Descripción
Cantidad
máxima de Cantidad máxima de MV sin contenido de
3.3. Selección del/los hipervisores MV cascarón aplicaciones relevantes que pueden correr.
Los autores consideran que la política por defecto RAM pro-
medio Utilización promedio de RAM para virtualizar
a seguir debe ser la utilización de LXC/LXD siempre un SO.
que se pueda. De no ser posible los autores propo-
nen el empleo de KVM como alternativa. Debido a la
naturaleza de OSLV, los autores recomiendan usar Para obtener la cantidad máxima de MV cascarón
el mismo SO en los contenedores que en los nodos que puede soportar el sistema anfitrión los autores
anfitriones. Para seleccionar el hipervisor los autores proponen el script de la Figura 5.
proponen el procedimiento mostrado en la Figura 4.
“VIII Simposio de Telecomunicaciones”
 Clavijo, D.; Moreno, D R., García, LR | “METODOLOGÍA PARA EL DIMENSIONAMIENTO DE LOS RECURSOS DE CÓMPUTO PARA PYME SOBRE NUBE
PRIVADA”

implementar soluciones SDN, ya sea en el momento

del diseño o en el futuro, la única opción viable en el
momento es OpenStack, aunque OpenNebula tiene
este aspecto contemplado en su roadmap.

NFS
KVM
Inicio Debian MV Ceph EV Proxmox
LXC
LVM
Figura 5 Script para evaluar eficiencia en hipervi-
sores
Ubuntu DSaaS VMWare ESXi OpenStack
Sustituir la línea 3 por el comando necesario para EH
iniciar una MV, agregando -$i al nombre de la nueva CentOS CDV Xen OpenStack/
MV. Por cada iteración se iniciará una nueva MV a OpenNebula

partir de una imagen base y se mostrará en pantalla

cuánta RAM va quedando disponible. Cuando el
script deje de responder se habrá encontrado la can- Figura 6 Diagrama de selección del CMP
tidad máxima de MV para este sistema. Dividir en-
tonces la cantidad de RAM del sistema anfitrión entre 3.4.1. Pruebas para evaluar los RNF de los
la cifra obtenida y ahí estará la métrica final de efi- CMP
ciencia. Teniendo en cuenta la longitud del conjunto de
3.4. Selección del CMP pruebas se mostrará la relativa a la elasticidad. La
elasticidad se desglosa en tres elementos: profundi-
La Figura 6 muestra el procedimiento propuesto
dad, velocidad y precisión.
para la selección del CMP. Dado que la propuesta
de los autores se basa en el empleo de OSLV com- Profundidad
plementado por KVM, el CMP más adecuado para Para evaluar cuán profundamente elástico es un
esto es Proxmox, ya que es la única que tiene so- sistema se debe otorgar un punto por cada una de
porte para producción con LXC. OpenStack y Open- las métricas propuestas en la Tabla 6. Para esto se
Nebula tienen soporte además para LXD, pero es debe consultar la documentación del producto.
desarrollado por terceros por lo que no se reco- Tabla 5 Mecanismos para lograr elasticidad
mienda para producción.
De elegir Proxmox los puntos negativos quedan Métrica Descripción
en cuanto a las capacidades de servicio y al OS. CPU en Capacidad de incrementar/disminuir la
Proxmox es una suite de virtualización basada en vivo cantidad de vCPU sin detener la MV
Debian con topología de clúster, por lo que todos los RAM en Capacidad de incrementar/disminuir la
vivo cantidad de RAM sin detener la MV
servidores de cómputo de la infraestructura deberán
tener como SO a Debian. Con este se puede brindar NIC en vivo Capacidad de agregar/retirar NIC sin
detener la MV.
IaaS utilizando RBACS ya que se pueden definir di-
Discos en Capacidad de agregar/retirar discos vir-
ferentes roles para los usuarios, pero no tiene una vivo tuales sin detener la MV.
vista enfocada al usuario final de la nube y carece de
Thin provi- Capacidad para consumir solamente el
RF como la definición de cuotas. Además de esto no sioning espacio en disco utilizado en vez del asig-
posee dispositivos virtuales de redes ej. enrutadores nado.
virtuales para brindar CDV. DSaaS no es un punto Compre- Capacidad para reclamar del disco vir-
crítico ya que existen muchas implementaciones sión de disco tual, el espacio en disco no utilizado y redu-
bien consolidadas de este servicio a nivel de aplica- cir el tamaño.
ción, sin embargo, si la entidad lo requiere integrado
al gestor la única opción viable es OpenStack. Velocidad
En el procedimiento primero se analiza el SO, Objetivo: Medir los tiempos de solicitud de recur-
luego las capacidades de servicio requeridas. Se sos
analiza el SA y luego la plataforma de virtualización,
en donde se considera emplear EV y los hiperviso- Realizar 10 iteraciones de los siguientes pasos
res. El proceso de selección natural está en azul, en 1- Crear una MV
cada una de las fases las alternativas presentan un 2- Utilizar el script anterior para obtener el
color que se corresponde con el CMP que puede tiempo de incremento/disminución de recur-
ofrecer el requerimiento presente. Nótese que todo sos virtuales.
puede lograrse con OpenStack. Si la entidad desea 3- Agregar [De soportarse]:
“VIII Simposio de Telecomunicaciones”
 Clavijo, D.; Moreno, D R., García, LR | “METODOLOGÍA PARA EL DIMENSIONAMIENTO DE LOS RECURSOS DE CÓMPUTO PARA PYME SOBRE NUBE
PRIVADA”
a. CPU en vivo
b. RAM en vivo
c. NIC en vivo
d. Discos en vivo
4- Retirar [De soportarse]
a. CPU en vivo
b. RAM en vivo
c. NIC en vivo
d. Discos en vivo
5- Realizar compresión de disco, de sopor-
tarse. El script también es válido.
Promediar los tiempos de incremento y disminu-
ción por recurso virtual. Las acciones pueden reali-
zarse vía GUI Web o empleando scripts. Los tiempos
son visibles en los registros del CMP. Se debe ade-
más evaluar la profundidad por hipervisor, ya que los
controladores de virtualización de los CMP en mu-
chas ocasiones limitan las funcionalidades que pue-
den ofrecer los hipervisores
Precisión
Determinar la relación recursos asignados / re-
cursos utilizados a lo largo de un intervalo de moni-
torización definido. Esta relación se encuentra calcu-
lando el área bajo la curva de cada una de las dos
funciones.
3.5. Dimensionamiento de los servidores
de cómputo
El dimensionamiento de los recursos de cómputo
de un CD está influenciado por muchas variables:
SA, hipervisores, CMP, cargas de trabajo y RNF. Se
debe estimar el número en bruto de cantidad de
RAM y CPU físicos necesarios ejecutar la carga de
trabajo de la entidad. Una vez hallado dichos valores
se procede a seleccionar los servidores de cómputo.
3.5.1. Estimación del poder de cómputo ne-
cesario
El procedimiento propuesto es:
1- En 3.2. se determinó la plantilla de MV ade-
cuada para cada componente de los servi-
cios de la entidad.
2- En 3.3. se determinó el hipervisor adecuado
para cada sub-servicio virtualizado. En fun-
ción de esto se reasignó la RAM si se migró
de una solución HVM a OSLV.
3- Obtener la sumatoria de RAM y CPU de to-
das las MV.
4- Agregar la cantidad de RAM y CPU según la
9 Cada nodo de Proxmox es de control y de computo
“VIII Simposio de Telecomunicaciones”
demanda existente en cuanto a IaaS.
5- Reducir la cifra anterior aplicando los índices
de consolidación según el hipervisor.
6- Sumar los requisitos de hardware del nodo
controlador según el CMP seleccionado,
consultar la documentación correspon-
diente. En el caso de Proxmox que presenta
topología clúster 9, dividir RAM en GB y nú-
cleos hasta el momento entre siete. Redon-
dear al entero superior y sumar dichas can-
tidades al conteo de RAM y CPU.
3.5.2. Selección del número y tipo de servi-
dores.
A partir del número total de CPU y RAM, se hace
necesario determinar el número de servidores COTS
que conformarán los nodos de cómputo del CD to-
mando como punto de partida la selección de una de
las estrategias de diseño:
- scale-up: concentrar el cómputo del CD en la
menor cantidad de servidores.
- scale-out: tener el cómputo del CD distribuido
en varios servidores.
Scale-up es la mejor opción debido a que se ga-
rantiza una mejor eficiencia energética, se utilizan
menor cantidad de puertos en los conmutadores y se
requiere menor cantidad de unidades de respaldo
energético. Sin embargo, esta variante tiende a ser
más costosa. Scale-out se propone como alternativa
si no se cuenta con presupuesto suficiente.
Para evitar la obsolescencia tecnológica y apro-
vechar al máximo los servidores, los autores propo-
nen utilizar la escalabilidad vertical al 100% y com-
prar servidores que tengan un soporte de cinco años
junto con las piezas de repuesto debido a la posible
ausencia de estas en un futuro. Se deben emplear
servidores rack de manera general y servidores
blade en presencia de aplicaciones HPC. Si el hard-
ware heredado no cumple con los números requeri-
dos de CPU y RAM realizar análisis de factibilidad
entre proveedores de servidores COTS para decidir
entre scale-up y scale-out teniendo en cuenta el pre-
supuesto asignado.
4. APLICACIÓN DE LOS PROCEDIMIENTOS
PROPUESTOS AL CD DE LA CUJAE
Para validar los instrumentos propuestos en el
documento se utilizó como escenario el CD de la red
CUJAE. Las pruebas activas se realizaron en un ser-
vidor de prueba. La red CUJAE presenta un sistema
 Clavijo, D.; Moreno, D R., García, LR | “METODOLOGÍA PARA EL DIMENSIONAMIENTO DE LOS RECURSOS DE CÓMPUTO PARA PYME SOBRE NUBE
PRIVADA”
de gestión de infraestructura de cómputo compuesto
por LXD como hipervisor principal auxiliado por KVM
y OpenNebula como CMP. Como SA se emplea
Ceph. La validación realizada fue parcial.
4.1. Caracterización de aplicaciones
Se realizaron todas las pruebas de QoS al servi-
cio de acceso a Internet para los usuarios de la CU-
JAE. Debido a las fallas previas ocurridas en el SA,
no se pudo contar con la cantidad de datos históricos
requerida, por lo que no se aplicó el método como
está propuesto. El intervalo de monitorización em-
pleado fue de 8:00 am a 6:00 pm el martes 19 de
mayo de 2017, un día típico acorde a la recomenda-
ción de los administradores. En la Tabla 7 se mues-
tran los datos generales del servicio.
Tabla 6 Datos generales del servicio de acceso a
Internet
Fueron monitorizados los índices de Throughput
y utilización de las aplicaciones existentes. Se pudo
que los proxy-cache consumen casi toda la memoria
que tienen asignada, por lo que a la hora de ubicar-
los en servidores de cómputo se deben colocar junto
a MV que hagan un uso intensivo de otro recurso vir-
tual. Esto no ocurre con los proxy-auth. Se pudiera
reducir la asignación de recursos virtuales. Los
proxy-auth emplean más CPU que los proxy-cache.
Para las pruebas de QoS se empleó solamente el
squid3. Se decidió comparar la QoS en tres configu-
raciones:
- Navegación local sin proxy
- Navegación local con proxy sin autentica-
ción
- Navegación local con proxy y autenticación
Se eligió como página de prueba http://telepor-
tal.cujae.edu.cu. El balanceo de carga de los proxys
no está correctamente implementado, los adminis-
tradores sugirieron 30 peticiones/segundo para mo-
delar la carga típica. Para las sobre-cargas se em-
plearon 90 peticiones/segundo.
En la Figura 7 se presenta la gráfica de carga ge-
nerada en Apache Jmeter. La prueba de carga fue
aplicada al squid3. Para ello se configuró en el squid
que solo el nodo generador de carga tuviese privile-
gios de acceso.
“VIII Simposio de Telecomunicaciones”
Figura 7 Carga generada con Apache Jmeter
No existe una diferencia apreciable entre métri-
cas con y sin autenticación. Sin embargo, la navega-
ción sin proxy es extremadamente más rápida com-
parando el throughput. El consumo de RAM y CPU
es mínimo en relación a los recursos asignados, 2GB
RAM y 1 vCPU, y que el servicio se degrada más
cuando existen variaciones abruptas en las solicitu-
des.
4.1.1. Conformación de la plataforma de vir-
tualización y sus respectivas pruebas
En el caso del CD de la Red CUJAE existe como
restricción el uso de OSLV auxiliado por HVM en la
plataforma de virtualización. Los administradores po-
seen preferencia por LXD. De esta restricción se de-
riva el empleo de Ubuntu como SO para los servido-
res de infraestructura de cómputo.
Para validar las pruebas realizadas al hipervisor
se empleó un servidor Intel Core i3-3240 @ 3.40GHz
con 2GB de RAM corriendo Ubuntu 16.04 en los con-
tenedores creados durante las pruebas no se les
aplicó limitación de recursos. Las pruebas se aplica-
ron a todos los RNF, pero solamente se muestra la
de eficiencia presentada anteriormente.
Eficiencia
Los autores utilizaron el comando lxc launch
e577368e2b89 lxd-test-$i para sustituir la línea de
crear e iniciar MV en el script propuesto.
e577368e2b89 se corresponde con la huella digital
de la imagen base utilizada para crear contenedores.
Destacar que a partir del contenedor 38 LXD co-
menzó a utilizar el área de intercambio de Linux que
en este caso es compartida con el servidor físico. El
contenedor 48 falló al iniciarse. El total fue de 191
contenedores luego de haber llenado el área de in-
tercambio y la RAM. La RAM promedio por contene-
dor fue de 21.5 MB.
4.1.2. Selección del CMP y sus respectivas
pruebas
Teniendo a LXD como restricción, ambas integra-
ciones de OpenStack y OpenNebula son desarrolla-
das por terceros. El autor no las recomienda para
 Clavijo, D.; Moreno, D R., García, LR | “METODOLOGÍA PARA EL DIMENSIONAMIENTO DE LOS RECURSOS DE CÓMPUTO PARA PYME SOBRE NUBE
producción. nova-lxd, integración de OpenStack, es
desarrollada por el mismo equipo que soporta a LXD,
sin embargo, hasta la fecha no es considerada in-
cluso una versión beta, no apareciendo en el listado
de hipervisores de OpenStack. LXDoNe, integración
de OpenNebula, ha tenido resultados satisfactorios
en entornos de prueba. OpenNebula es entonces el
CMP más adecuado.
Las pruebas se aplicaron a todos los RNF, pero
solamente se muestra la de elasticidad presentada
anteriormente.
Elasticidad
OpenNebula hasta la fecha solamente soporta la
agregación y retiro de NIC y discos duros como me-
canismos de EV. Los tiempos de agregación de dis-
cos son variables en dependencia del respaldo de
almacenamiento utilizado, de ser distribuido la red y
la cantidad de tráfico presente influyen también. Para
estas pruebas se utilizó almacenamiento local. Los
resultados se muestran en la Tabla 11
Tabla 7 Rapidez de elasticidad en OpenNebula
Métrica Agregar [se- Retirar
gundos] gundos]
NIC en vivo 6.03 1.57
Discos en 2.15 1.48
vivo
4.1.3. Evaluación de los RNF de los nodos
de cómputo
Se realizaron pruebas de microbenchmark en el
servidor propuesto anteriormente y se compararon
los resultados en la MV respecto a los del servidor.
La Figura 8 muestra algunos resultados útiles para
comparativas con otros servidores o hipervisores.
Figura 8 Encriptación de los datos y la cache del
CPU
Figura 9 Throughput de la RAM
“VIII Simposio de Telecomunicaciones”
PRIVADA”
Figura 10 Desempeño del CPU con 1 hilo de ejecu-
ción
5. CONCLUSIONES
En el presente trabajo se proponen procedimien-
tos para el diseño de los recursos de cómputo y la
selección de CMP para NP con soporte para IaaS
para PyME. Los resultados alcanzados aportan al di-
seño de infraestructuras de NP basadas en hard-
ware de propósito general y SLCA, dotándoles de un
enfoque de diseño desde la perspectiva del negocio,
impactando positivamente en las inversiones de ca-
[se- pital y de operaciones del CD, así como en la inde-
pendencia tecnológica.
Los objetivos fueron parcialmente validados en el
CD de la Red CUJAE. Se logró evaluar el comporta-
miento del servicio de acceso a internet para los
usuarios de la red CUJAE con las pruebas de QoS y
las pruebas de monitorización. Se aplicó el conjunto
de procedimientos para evaluar hipervisores a LXD.
Se aplicó el conjunto de procedimientos para evaluar
CMP, al CMP OpenNebula. El trabajo propuesto se
considera un manual útil para dimensionar los recur-
sos de computo de PyME.
6. REFERENCIAS BIBLIOGRÁFICAS
[1] V. K. Manik and D. Arora, “Performance compari-
son of commercial VMM: ESXI, XEN, HYPER-V
KVM,” presented at the 2016 3rd International Con-
ference on Computing for Sustainable Global De-
velopment (INDIACom), 2016, pp. 1771–1775.
[2] R. Birke, A. Podzimek, L. Y. Chen, and E. Smirni,
“Virtualization in the Private Cloud: State of the
Practice,” Sep. 2016.
[3] G. Galante, L. C. E. D. Bona, A. R. Mury, B.
Schulze, and R. da R. Righi, “An Analysis of Public
Clouds Elasticity in the Execution of Scientific Ap-
plications: a Survey,” J. Grid Comput., vol. 14, no.
2, pp. 193–216, Jun. 2016.
[4] Y. Yamato, “Performance-aware server architecture
recommendation and automatic performance verifi-
cation technology on IaaS cloud,” Serv. Oriented
Comput. Appl., pp. 1–15, Nov. 2016.
 Clavijo, D.; Moreno, D R., García, LR | “METODOLOGÍA PARA EL DIMENSIONAMIENTO DE LOS RECURSOS DE CÓMPUTO PARA PYME SOBRE NUBE
PRIVADA”
[5] “Vmware Vsphere 5.X Datacenter Design Cook-
book - pdf - Read Book Online.” [Online]. Availa-
ble: http://www.allitebooks.com/read/in-
dex.php?id=19977. [Accessed: 30-Mar-2017].
[6] “vsphere-esxi-vcenter-server-60-installation-setup-
guide.pdf.” 2015.
[7] “Service & Warranty Support,” Inspur, 16-May-
2017. .
[8] “Huawei FusionServer and Tecal Servers —
Huawei products,” 2017. [Online]. Available:
http://e.huawei.com/en/products/cloud-computing-
dc/servers. [Accessed: 26-May-2017].
[9] “Servidores - Sistemas de servidores de PCs empre-
sariales y soluciones de red,” 2017. [Online]. Avail-
able: https://www.hpe.com/es/es/servers.html. [Ac-
cessed: 26-May-2017].
[10] José Guillermo Ramírez Gil, Frank Ernesto Tarrau
Prendes, and Lilia Rosa García, “PROPUESTA DE
PRUEBAS PARA EVALUAR EL DESEMPEÑO
DE NUBES PRIVADAS CON SOPORTE PARA
IAAS,” presented at the 18 Convención Científica
de Ingeniería y Arquitectura, Palacio de Convencio-
nes de La Habana, 2016, pp. 867–880.
7. SÍNTESIS CURRICULARES DE LOS AU-
TORES
“VIII Simposio de Telecomunicaciones”
Daniel Clavijo Coca es un profesor e investigador de la CUJAE
especializado en tecnologías libres en el área de la computación en
la nube, redes, virtualización y servicios telemáticos. Es uno de los
integrantes del proyecto CloX y parte de los desarrolladores del
controlador LXDoNe. Asistió de manera voluntaria en el rediseño del
centro de datos del Ministerio de la Agricultura.
Dennys R. Moreno Véliz espcialista en Telemática del MININT.
Lilia Rosa García Perellada: Ingeniera en Telecomunicaciones y
Electrónica graduada en La Universidad Tecnológica de La Ha-
bana (CUJAE), La Habana, Cuba. Tiene un Master de la universi-
dad CUJAE también. Es una profesora asistente en el Departa-
mento de Telecomunicaciones y Telemática de la CUJAE.
Sergio Vega Gutiérrez: Ingeniero en Telecomunicaciones y Elec-
trónica graduado en La Universidad Tecnológica de La Habana
(CUJAE), La Habana, Cuba. Actualmente trabajando en la Direc-
ción de Servicios de las Tecnologías de la Información y las Co-
municaciones (DISERTIC) de la CUJAE.
José M. de la Fé: Ingeniero en Telecomunicaciones y Electrónica
graduado en La Universidad Tecnológica de La Habana (CUJAE),
La Habana, Cuba.
Alain Abel Garófalo Hernández: Ingeniero en Telecomunicaciones
y Electrónica graduado en La Universidad Tecnológica de La Ha-
bana (CUJAE), La Habana, Cuba. Tiene un Master y un Docto-
rado de la universidad CUJAE también. Es un profesor asistente
adjunto en el Departamento de Telecomunicaciones y Telemática
de la CUJAE.