Universidad Politcnica de Madrid

Escuela Tcnica Superior de Ingenieros de Telecomunicacin

DESARROLLO DE PROPUESTA
DE ARQUITECTURA ABIERTA PARA LA GESTIN
DE CONFIGURACIN Y ADMINISTRACIN DE
RECURSOS EN CENTROS DE DATOS

TRABAJO FIN DE MSTER

Roberto Saavedra Neira

2013
 Universidad Politcnica de Madrid
Escuela Tcnica Superior de Ingenieros de Telecomunicacin

Mster Universitario en
Ingeniera de Redes y Servicios Telemticos

TRABAJO FIN DE MSTER

DESARROLLO DE PROPUESTA
DE ARQUITECTURA ABIERTA PARA LA GESTIN
DE CONFIGURACIN Y ADMINISTRACIN DE
RECURSOS EN CENTROS DE DATOS

Autor
Roberto Saavedra Neira

Director
Prof. David Fernndez Cambronero

Departamento de Ingeniera de Sistemas Telemticos

2010
Resumen

Los centros de datos son una parte clave de la infraestructura sobre la que se
construyen gran variedad de servicios de tecnologa de la informacin. Como
los centros de datos siguen creciendo en tamao y complejidad, es conveniente
entender los aspectos de su diseo que son dignos de llevar adelante, as como
las deficiencias y los retos existentes o futuros que tendran que abordarse.

En los ltimos aos, las tecnologas y los mercados relacionados con los
centros de datos han sido objeto de rpidos cambios y crecimiento. Los centros
de datos estn jugando un papel importante en la implementacin de
Infraestructura TIC y en la promesa para convertirse en una plataforma comn
para casi todas las infraestructuras sociales. A pesar de que la investigacin se
han centrado en las tecnologas de redes, otros estudios son necesarios para el
desarrollo de centros de datos a gran escala, de alto rendimiento, rentable y
flexible. Para entender mejor estas tecnologas, examinamos los esfuerzos de
investigacin, desarrollo y recientes resultados, de acuerdo con la taxonoma de
un centro de datos.

De acuerdo con muchos cambios, tales como el nmero de usuarios, el

volumen de los datos analizados / procesados, y la complejidad de la lgica de
servicio proporcionado, el papel y la configuracin de los centros de datos han
cambiado drsticamente. Se han vuelto ahora ms abiertos y basados en
tecnologas de servicios, a una mayor escala, ms eficientes energticamente y
ms ampliamente distribuidos para manejar la mezcla de gran nmero de
clientes atendidos.

Tenemos la visin de la evolucin del centro de datos en las entidades fsicas

propias de las infraestructuras potencialmente tercerizadas, virtualizadas y
distribuidas geogrficamente que an tratan de proporcionar el mismo nivel de
control y aislamiento que las infraestructuras en propiedad. El presente trabajo
se define un modelo de capas para este tipo de centros de datos y se
proporciona un anlisis detallado del estado de la tcnica y los nuevos desafos
en la gestin y administracin del almacenamiento, las redes, la gestin y los
aspectos trmicos y de energa.

i
Abstract

Data centers form a key part of the infrastructure upon which a variety of
information technology services are built. As data centers continue to grow in
size and complexity, it is desirable to understand aspects of their design that are
worthy of carrying forward, as well as existing or upcoming shortcomings and
challenges that would have to be addressed.

In recent years, technologies and markets related to data centers have been
rapidly changing and growing. Data centers are playing an important role in
ICT infraestructura deployment and promise to become common platforms for
almost all social infraestructures. Even though research have been focused on
networking technologies, various are needed to develop high-performance,
cost-efficient, and flexible large-scale data centers. To understand these
technologies better, we survey recent research and development efforts and
results in accordance with a data center network taxonomy.

In accordance with many changes, such as the number of users, the volumen
of analyzed / processed data, and the complexity of the provided service logic,
the role and configuration of data centers have changed drastically. They have
now become more open an based on commodity technologies, larger scale,
greener and more widely distributed to handle the mixture of huge number of
customers serviced.

We envision the data center evolving from owned physical entities to

potentially outsourced, virtualized and geographically distributed
infrastructures that still attempt to provide the same level of control and
isolation that owned infrastructures do. We define a layered model for such
data centers and provide a detailed treatment of state of the art of
confirguration management and administration, as well as emerging challenges
in storage, networking, management, power and thermal aspects.

iii
ndice general

Resumen .................................................................................................................................. i

Abstract .................................................................................................................................. iii

ndice general ......................................................................................................................... v

ndice de figuras .................................................................................................................. vii

Siglas ...................................................................................................................................... ix

1 Introduccin......................................................................................................................1

2 Organizacin y problemas del centro de datos ...........................................................3

2.1 Organizacin fsica ...................................................................................................3

2.2 Almacenamiento e infraestructura de red.............................................................4

2.3 Infraestructura de gestin ........................................................................................5

2.4 Infraestructura elctrica y refrigeracin ................................................................7

2.5 Los principales problemas del centro de datos ....................................................8

3 Evolucin de los Centros de Datos ..............................................................................11

4 Infraestructura de Red en Centros de Datos ..............................................................14

4.1 El stack Ethernet ......................................................................................................14

4.2 Desafos de las Redes en Centros de Datos .........................................................18

4.3 VXLan : Superando el lmite de VLans ................................................................23

5 Almacenamiento en los Centros de Datos .................................................................29

5.1 Conceptos bsicos de almacenamiento................................................................29

5.2 Almacenamiento en discos de estado slido e hbridos....................................33

5.3 Desafos en el almacenamiento .............................................................................35

6 Gestin de la configuracin en los centros de datos .................................................38

6.1 Gestin del ciclo de vida ........................................................................................38

6.2 Marcos operacionales de gestin ..........................................................................40

6.3 Almacenamiento de datos de gestin ..................................................................41

6.4 Desafos en la Provisin de Servicios ...................................................................45

6.5 Desafos en la Gestin de Procesos ......................................................................47

v
7 Requisitos de la Gestin de Recursos en Centros de Datos .....................................50

7.1 Monitorizacin ........................................................................................................53

7.2 Anlisis de Informacin en Tiempo Real ............................................................55

7.3 Evolucin de las Arquitecturas abiertas en la Gestin de Recursos................56

8 OpenQRM : Plataforma Abierta de Gestin de Centros de Datos .........................58

8.1 Concepto, Diseo y Arquitectura .........................................................................60

8.2 Aprovisionamiento El modelo de Recursos OpenQRM ................................62

8.3 Capa de Almacenamiento......................................................................................63

8.4 Gestor de Virtualizacin ........................................................................................64

8.5 Monitorizacin ........................................................................................................64

8.5.1 Nagios ................................................................................................................65

8.5.2 Collectd ..............................................................................................................66

8.5.3 Zabbix ................................................................................................................66

8.6 Consideraciones respecto de la Seguridad ..........................................................67

8.7 Desarrollo e Integracin de Mdulos Adicionales .............................................68

9 Prueba de Concepto : Integracin de Gestin de VLANs........................................70

9.1 HP VLAN Administration .....................................................................................70

9.2 ShellInABox .............................................................................................................71

9.3 Integracin en OpenQRM y Escalabilidad ..........................................................71

Conclusiones .........................................................................................................................72

Bibliografa ............................................................................................................................73

vi
ndice de figuras

Figura 1. Infraestructura de Datacenter y Gestin de TI ..................................................3

Figura 1. Arquitectura de Red Convencional vs. Arquitectura de N-aria de
Topologa Fat Tree .......................................................................................................................5
Figura 3. Topologa de Red : Nivel de Core, Agregacin y Acceso ................................6
Figura 4. Sistema de Enfriamiento por A/C tipo Crac-Up (Suelo Tcnico) ..................7
Figura 5. La Gestin de Recursos en Centros de Datos ....................................................9
Figura 6. Modelo de Conceptual de Capas : Infraestructura Virtual e Infraestructura
Fsica ............................................................................................................................................12
Figura 7. Ubicacin del Etiquetado VLAN en una trama Ethernet ..............................15
Figura 8. Flujo de Informacin del Protocolo SCTP ........................................................17
Figura 9. Bits de Clase de Servicio en una Trama Ethernet .........................................21
Figura 10. Ubicacin del Campo VXLAN ID (24 Bits) ....................................................24
Figura 11. Encapsulamiento del encabezado VXLAN ....................................................25
Figura 12. Caractersticas de diversas Interfaces de Almacenamiento ........................30
Figura 13. Memoria de Ncleo Magntico (a) y Ferro-Elctrica (b) .............................33
Figura 14. Controlador de Memoria Flash .......................................................................35
Figura 15. Componentes de CIM (Common Information Model) ................................42
Figura 16. Gestin de Infraestructura : Capa de Control (Underware)........................51
Figura 16. Integrated Data Center Infrastructure Management....................................53
Figura 17. Gestin de IT y Servicios de Negocio (DCIM) ..............................................54
Figura 18. Interfaz de Gestin OpenQRM ........................................................................59
Figura 19. Interfaz Administrativa de Nagios .................................................................65
Figura 20. Interfaz de Monitorizacin Zabbix.................................................................66
Figura 21. Gestin web de VLANs en Switches HP ProCurve ....................................70

vii
Siglas

AC (Altern Current) : Corriente Alterna

AOE (ATA over Ethernet) : ATA sobre Ethernet

ATA (Advanced Technology Attachment) : Tecnologa Avanzada de Adicin

BMC (Board Main Controller) : Controlador Principal de Placa Base

CDA (Common Data Access) : Acceso Comn de Datos

CFS (Cluster File System) : Sistema de Ficheros en Clster

CGI (Common Gateway Interface) : Interfaz de Pasarela Comn

CIM (Common Information Model) : Modelo Comn de Informacin

CIM-DB (CIM Database) : Base de Datos CIM

CIMOM (CIM Object Model) : Modelo de Objetos CIM

CLOS Network (Charles Clos) : Modelo de Red de Charles Clos basado en circuitos

CMDB (Configuration Management DB) : Base de datos de Gestin de Configuracin

CoS (Class of Service) : Clase de Servicio

CPD : Centro de Procesamiento de Datos

CRC (Cyclic Redundancy Check) : Chequeo de Redundancia Cclica

CSS (Cascading Style Sheets) : Hojas de Estilo en Cascada

CST (Central Superior Tree) : Arbol de Expansin Superior Central

DAS (Directly Attached Storage) : Almacenamiento Directo Adjunto

DC (Direct Current) : Corriente Directa

DCIM (Datacenter Infrastructure Management) : Gestin de Infraestructura de CPD

DMTF (Distributed Management Task Force) : Grupo de Trabajo de Gestin

Distribuda

DoS (Denial of Service) : Denegacin de Servicio

DVDC (Distributed Virtual Data Center) : CPD Virtual Distribudo

E/S : Entrada / Salida

ix
EC2 (Elastic Cloud 2) : Nube Elstica 2 de Amazon

ECMP (Equal Cost Multi-Path) : Multi-trayecto de Coste Equivalente

EMP (External Management Packages) : Paquetes de Gestin Externos

FC (FibreChannel) : Tecnologa de Comunicacin por Canal de Fibra

FCIP (FibreChannel over IP) : FC sobre Protocolo Internet

FeRAM (Ferro-Electric Random Access Memory) : Memoria de Acceso Aleatorio Ferro-

Elctrica

FPGA (Field Programmable Grid Array) : Arreglo de Malla Programable en Campo

FTL (Flash Translation Layer) : Capa de Traduccin de Memoria Flash

GC (Garbage Collector) : Recolector de Memoria no utilizada

GPFS (General Parallel Filesystem) : Sistema General de Ficheros Paralelos de IBM

GRD (Global Reference Directory) : Directorio de Referencia Global

Host : Servidor Anfitrin

IANA (Internet Assigned Numbers Authority) : Autoridad de Asignacin de Nmeros

Internet

IBA (In-Band Access) : Acceso Dentro de Banda

IP (Internet Protocol) : Protocolo Internet

IPC (Inter-Process Communications) : Comunicaciones Inter-Procesos

iSCSI : Internet SCSI (Small Computer System Interface)

ISP (Internet Service Provider) : Proveedor de Servicios Internet

KVM (Keyboard Video Mouse) : Teclado Video Ratn

LAN (Local rea Network) : Red de rea Local

LDAP (Lightweight Directory Access Protocol) : Protocolo Ligero de Acceso a

Directorios

LVM (Logical Volume Manager) : Gestor de Volmenes Lgicos

MAC (Medium Access Control) : Control de Acceso a Medio

MLC (Multi-Level Cell) : Celda Multi-Nivel

MPLS (Multi-Protocol Layering System) : Sistema de Etiquetado Multi-Protocolo

MRAM (Magnetic RAM) : Memoria RAM Magntica

x
NAND (Negated AND) : Compuerta Lgica de Negacin AND o Not AND

NAS (Network Attached Storage) : Almacenamiento Adjunto a Red

NAT (Network Address Translation) : Traduccin de Direccin de Red

NFS (Network File System) : Sistema de Ficheros en Red

NIC (Network Interface Card) : Tarjeta de Interfaz de Red

NVRAM (Non-Volatile RAM) : Memoria RAM no voltil

OOB (Out-of-Band) : Comunicaciones Fuera de Banda

P2P (Physical to Physical) : Servidor fsico a Servidor fsico

P2V (Physical to Virtual) : Servidor fsico a Servidor virtual

PaaS (Platform as a Service) : Plataforma como Servicio

PAM (Pluggable Authentication Module) : Mdulo Conectable de Autenticacin

PByte (PetaByte) : 1015 Bytes

PCI (Peripheral Component Interconnect) : Interconexin de Componentes Perifricos

PCM (Phase Changing Memory) : Memoria de Cambio de Fase

PDU (Power Distribution Unit) : Unidad de Distribucin de Energa

PHY (Physical Layer) : Nivel Fsico

PIL (Physical Infrastructure Layer) : Capa de Infraestructura Fsica

PRAM (Phase-Change RAM) : Memoria de Cambio de Fase

PVFS (Parallel Virtual Filesystem) : Sistema de Ficheros Paralelo Virtual

PXE (Pre-boot Execution Environment) : Ambiente de Ejecucin Pre-inicial

QoS (Quality of Service) : Calidad de Servicio

RDMA (Remote Direct Access Memory) : Memoria de Acceso Directo Remoto

RSVP-TE (Resource Reservation Protocol for Traffic Engineering) : Protocolo de

Reserva de Recursos para Ingeniera de Trfico

RTT (Roundtrip Time) : Tiempo de Ida y Vuelta de paquetes

SaaS (Software as a Service) : Software como Servicio

SAN (Storage Area Network) : Red de rea de Almacenamiento

SAS (Serial Attached SCSI) : SCSI de Adicin Serial

xi
SATA (Serial Advanced Technology Attachment) : Tecnologa Avanzada de Adicin
Serial

SCSI (Small Computer System Interface) : Interfaz de Sistema de Ordenadores

Pequeos

SCTP (Streaming Control Transmission Protocol) Protocolo de Control de Transmisin

de Streaming

SERD (Scalable Enterprise Resource Directory) : Directorio de Recursos Empresariales

Escalable

SLA (Service Level Agreement) : Acuerdo de Nivel de Servicio

SML (Service Modelling Language) : Lenguaje de Modelado de Servicios

SOAP (Simple Object Access Protocol) : Protocolo Simple de Acceso a Objetos

SPL (Service Provider Layer) : Capa de Proveedor de Servicios

SS7 (Signalling System Number 7) : Sistema de Sealizacin Nmero 7

SSD (Solid State Disk) : Disco de Estado Slido

STP (Spanning Tree Protocol) : Protocolo de Arbol de Expansin (Switches)

TCP (Transmission Control Protocol) : Protocolo de Control de Transmisin

TPM (Tampering-proof Memory) : Memoria a prueba de manipulaciones

UDP (User Datagram Protocol) : Protocolo de Datagramas de Usuario

UML (Unified Modelling Language) : Lenguaje de Modelado Unificado

UPS (Uninterrupted Power Supply) : Sistema de Alimentacin Ininterrumpida

USB (Universal Serial Bus) : Bus Serial Universal

UWB (Ultra Wide Band) : Banda Ultra Ancha

V2P (Virtual to Physical) : Servidor virtual a Servidor fsico

V2V (Virtual to Virtual) : Servidor virtual a Servidor virtual

VC (Virtual Cluster) : Clster Virtual

VDC (Virtual Datacenter) : CPD Virtual

VICL (Virtual Infrastructure Coordination Layer) : Capa de Coordinacin de

Infraestructura Virtual

VIL (Virtual Infrastructure Layer) : Capa de Infraestructura Virtual

VLAN (Virtual Local Area Network) : Red de rea Local Virtual

xii
VM (Virtual Machine) : Mquina Virtual

VNI (Virtual Lan Network ID) : Identificador de VLAN

VPN (Virtual Private Network) : Red Privada Virtual

VR (Voltage Regulator) : Regulador de Voltaje / Tensin

VTEP (Virtual Tunnel End-point) : Extremo final de Tnel Virtual

W3C : World Wide Web Consortium

WBEM (Web-based Enterprise Management) : Gestin Empresarial basada en Web

WSMAN (Web Services Management) : Gestin de Servicios Web

ZFS (Sun Microsystems Zettabyte Filesystem) : Sistema de Ficheros Zettabyte de Sun

Microsystems

Zipf (George Kingsley Zipf Empirical Law) : Ley Emprica de Estadsticas Matemticas
de George Kingsley Zipf

xiii
1 Introduccin

Los centros de datos son la columna vertebral de una amplia variedad de

servicios ofrecidos a travs de Internet como Web-hosting, comercio electrnico,
redes sociales, y una variedad de servicios ms generales, tales como el
software como servicio (SaaS), plataforma como servicio (PaaS ) y cloud
computing. Algunos ejemplos de estas plataformas de servicios genricos son
Microsoft Azure, Google App Engine, Amazon EC2 y Oracle Grid Engine. La
virtualizacin es la clave para ofrecer muchos de estos servicios y se est
utilizando cada vez ms en los centros de datos para lograr una mejor
utilizacin de los servidores y la asignacin de recursos ms flexible. Sin
embargo, la virtualizacin tambin hace que muchos aspectos de la gestin del
centro de datos ms desafiante.

A medida que la complejidad, la variedad y la penetracin de estos servicios

crece, los centros de datos seguir creciendo y proliferando. Varias fuerzas
estn dando forma al paisaje del centro de datos y esperamos que los futuros
centros de datos sean mucho ms que simplemente versiones ms grandes de
las que hoy existen. Estas tendencias emergentes, que se explican con ms
detalle en el Captulo 3, muestran que los centros de datos evolucionan hacia
sistemas distribuidos en infraestructuras virtualizadas de varias capas, que
presentan una serie de retos difciles.

En el presente trabajo, ofrecemos una cobertura tutorial de una serie de

nuevos problemas en el diseo y la gestin de grandes centros de datos. En
particular, consideraremos un modelo de capas de los centros de datos y
discutiremos aspectos de almacenamiento, redes, gestin, y problemas trmicos
del modelo. Debido a la amplitud de estos temas, hemos de evitar el
tratamiento detallado de algunos temas ya investigados. En particular, no se
profundizar en los entresijos de las tcnicas de virtualizacin, migracin de
mquinas virtuales y programacin en entornos virtualizados.

La organizacin del trabajo es la siguiente. En el Captulo 2 se analiza la

organizacin de un centro de datos y seala varias reas difciles en la gestin
del centro de datos. En el Captulo 3 se discuten las tendencias emergentes en

1
centros de datos y las nuevas cuestiones planteadas por ellos. Las siguientes
secciones se discuten temas especficos en detalle, incluyendo almacenamiento,
redes, gestin de energa y problemas trmicos. Por ltimo, se propone una
arquitectura abierta para la gestin de la configuracin de elementos de red,
basada en software de cdigo abierto y se presenta una prueba de concepto. En
particular, se abordan las capacidades y caractersticas de la herramienta
OpenQRM, como plataforma de gestin que combina las funcionalidades
requeridas para la eficaz administracin y gestin de la infraestructura del
centro de datos.

2
2 Organizacin y problemas del centro de datos

2.1 Organizacin fsica

Un centro de datos est organizado en general, en filas de bastidores o racks,
donde cada rack contiene activos modulares tales como servidores, switches de
almacenamiento o aparatos especializados. Un rack estndar es de 78 pulgadas
de alto, 23 - 25 cm de ancho y 26 a 30 cm de profundidad. Por lo general, cada
rack tiene una serie de mdulos "para montaje en rack" activos insertados
horizontalmente en los bastidores. El espesor de estos mdulos se mide
utilizando una unidad llamada "U", que es de 45 mm (aproximadamente 1,8
pulgadas). Una gran mayora de los servidores de uno o dos sockets se pueden
adaptar al tamao 1U.

Un rack estndar puede tomar un total de 42 equipos de 1U cuando est

completamente lleno. La sofisticacin del bastidor puede variar en gran
medida. Las caractersticas adicionales pueden incluir la distribucin de
potencia por rack, una funcin de KVM (teclado - video - mouse), aire
acondicionado a nivel de bastidor o refrigeracin lquida, y tal vez incluso una
unidad de gestin de nivel de rack.

Figura 1. Infraestructura de Datacenter y Gestin de TI

Para una mayor eficiencia en su funcionalidad, los servidores pueden ser

alojados en un chasis autnomo que a su vez se desliza en el bastidor. El chasis
proporciona ranuras de tamao estndar que se podra insertar activos
modulares (generalmente conocido como Blades). Un solo chasis puede
albergar hasta 16 servidores 1U, proporcionando as una capacidad terica de
rack de 96 activos modulares.

El aumento sustancial en la densidad de servidores alcanzable mediante el

3
uso de Blades tiene un correspondiente incremento en el consumo de energa
por rack, que a su vez pueden impactar de manera importante la
infraestructura de distribucin de energa. En particular, muchos centros de
datos estn diseados con alrededor de 7 KW de potencia por rack, mientras
que bastidores cargados con servidores Blade que pueden acercarse a 21 KW.

Existe un problema similar con respecto a la densidad trmica. La

infraestructura de refrigeracin puede ser incapaz de manejar la carga trmica
que se produce en la operacin de los servidores, y como resultado puede ser
inviable cargar los bastidores a su capacidad total.

2.2 Almacenamiento e infraestructura de red

El almacenamiento en centros de datos puede estar disponible en varias
presentaciones. A menudo, el almacenamiento de alto rendimiento se
encuentra en "torres de almacenamiento" especiales que permiten el acceso
remoto transparente, independientemente de la cantidad y el tipo de
dispositivos de almacenamiento fsicos utilizados. El almacenamiento tambin
se puede proporcionar en bloques ms pequeas situados en rack o ranuras del
chasis o directamente integrado con los servidores. En todos los casos, el acceso
eficiente a la red para el almacenamiento es crucial.

Un centro de datos requiere tpicamente cuatro tipos de accesos de red, y

potencialmente podra utilizar cuatro tipos diferentes de redes fsicas.
Mediante una arquitectura cliente / servidor de red se permite el acceso externo
a los centros de datos, utilizando necesariamente una tecnologa de productos
elementales como el cable Ethernet o Fibra Optica. El acceso al almacenamiento
tradicionalmente ha sido proporcionada por canal de fibra, pero tambin podra
utilizar Ethernet o Infiniband. La red que se utiliza para la gestin tambin es
tpicamente Ethernet pero puede usar cableado separado o existir como una
"banda lateral" en la red convencional.

Las redes de almacenamiento y de propsito general suelen seguir

configuracin similar. Para los servidores Blade montados sobre un chasis, ste
ltimo proporciona un conmutador o switch a travs de la cual todos los
servidores del chasis se conectan a servidores externos. Estos switches
generalmente disponen de conectividad dplex para la fiabilidad y se pueden
organizar para carga compartida.

4
 Figura 2. Arquitectura de Red Convencional vs. Arquitectura de N-aria de Topologa Fat Tree

A fin de mantener la red manejable, la topologa general es bsicamente un

rbol con conectividad total en el nivel raz. Por ejemplo, cada nivel del chasis
(o nivel 1) tiene un switch de enlace ascendente que conduce al switch de nivel
2, por lo que la comunicacin entre dos servidores en diferentes chasis debe ir a
travs de, al menos, tres switches. Dependiendo del tamao del centro de datos,
los mltiples switches pueden ser conectados en una malla completa, o a travs
de uno o ms conmutadores de nivel 3.

El mayor problema con esta estructura es la posible insuficiencia de ancho de

banda en los niveles superiores. En general, los enlaces ascendentes estn
diseados para una relacin de exceso de especfica, ya que proporcionar un
ancho de banda de biseccin completo es por lo general no viable. Por ejemplo,
20 servidores, cada uno con conectividad Ethernet de 1 Gbps pueden compartir
una sola conexin Ethernet de enlace ascendente de 10 Gbps para una relacin
de exceso de 2,0. Esto puede ser problemtico si la asignacin de carga de
trabajo es tal que existe una comunicacin no local sustancial. Como el
almacenamiento se ofrece tradicionalmente en una torre de almacenamiento
por separado, todo el trfico de almacenamiento generalmente atraviesa el
enlace ascendente del chasis en la red de almacenamiento. Como los centros de
datos crecen en tamao, una arquitectura de red ms escalable se hace
necesaria.

2.3 Infraestructura de gestin

Cada servidor por lo general lleva un controlador de administracin llamado
BMC (controlador de gestin de placa base). La red de gestin termina en el
BMC de cada servidor. Cuando la red de gestin se implementa como una red
de "banda lateral", no se requieren switches adicionales. De lo contrario, se
requiere un conmutador de gestin en cada chasis / bastidor para soportar la

5
comunicacin externa. Las funciones bsicas de la BMC incluyen el monitoreo
de varios sensores de hardware, gestin de hardware diferentes y alertas de
software, arrancar y apagar el servidor, el mantenimiento de los datos de
configuracin de varios dispositivos y controladores, y proporcionar
capacidades de administracin remota. Cada chasis o bastidor pueden integrar
en s mismo un controlador de administracin de nivel superior que se
comunica con el controlador de nivel inferior.

Figura 3. Topologa de Red : Nivel de Core, Agregacin y Acceso

La gestin de la configuracin es un trmino bastante genrico que puede

referirse a la gestin de la configuracin de los parmetros de una variedad de
objetos que son de inters en la utilizacin eficaz de la infraestructura del
sistema informtico y de dispositivos individuales, hasta servicios complejos
que se ejecutan en grandes grupos en red. Parte de esta gestin pertenece
claramente al controlador de gestin de placa base (BMC) o de la cadena de
gestin de nivel superior correspondiente.

Esto a menudo se conoce como gestin fuera de banda (OOB), ya que se

realiza sin intervencin de la CPU principal o el sistema operativo. Otras
actividades pueden ser ms apropiadas para su administracin en banda
lateral, y pueden ser realizadas por la CPU principal, en el sistema operativo, o
en el middleware. La gestin de nivel superior puede ejecutarse en sistemas
separados que tienen tanto fuera de banda como dentro de banda. En un
servidor, las funciones ms crticas OOB pertenecen a la fase de pre-arranque y
en la vigilancia de la integridad del servidor, mientras que el sistema operativo
se est ejecutando. En otros equipos, tales como switches, routers, y bloques de
almacenamiento, la gestin es necesariamente OOB.

6
2.4 Infraestructura elctrica y refrigeracin
Incluso los centros de datos de tamao medio pueden tener un consumo de
energa mximo de varios megavatios. Para tales cargas de energa, se hace
necesario utilizar suministros de alta tensin (por ejemplo, 15 KV en tres fases)
conjuntamente con un sistema de transformacin en las instalaciones a 240V a
travs de un sistema de alimentacin ininterrumpida (UPS ). La unidad UPS
debe convertir AC a DC para cargar sus bateras y luego convertir DC a AC en
el extremo de salida. Dado que la unidad UPS se encuentra directamente en el
circuito de alimentacin, se puede seguir suministrando potencia de salida
ininterrumpida en caso de prdida de potencia de entrada. La salida de la UPS
(por lo general 240/120 V, en sola fase) se encamina a la unidad de distribucin
de energa (PDU) que, a su vez, suministra alimentacin a los servidores
instalados en bastidor o chasis de Blades individuales. A continuacin, la
potencia es reducida, convirtiendo la corriente alterna (AC) en corriente directa
(DC) parcialmente regulada, a fin de producir los tpicos 12V y 5V de salida,
con los valores de corriente deseados (20 - 100 A). Estos voltajes son entregados
a la placa base, donde los reguladores de tensin (VR) deben convertirla en
diversos valores de voltaje, segn las exigencias de diseo del servidor.

Cada una de estas etapas de conversin y distribucin de energa resulta en

prdida de potencia, con algunas etapas que muestran eficiencia en un rango de
85 - 95%. Por lo tanto, no es sorprendente que la eficiencia de energa
acumulada en el voltaje final de la placa base de servidores y equipos de
almacenamiento y red es slo el 50% o menos (sin considerar la refrigeracin,
iluminacin y otros usos de energa auxiliar). Existe por lo tanto un margen
importante para lograr una mayor eficiencia de energa mediante un mejor
diseo de transformacin y distribucin de energa.

Figura 4. Sistema de Enfriamiento por A/C tipo Crac-Up (Suelo Tcnico)

La infraestructura de refrigeracin en un centro de datos puede ser muy

compleja y costosa, implicando varias unidades de aire acondicionado que

7
requieren plantas enfriadoras, ventiladores y sistemas de recirculacin de aire.
La evolucin de las tecnologas de refrigeracin tienden a enfatizar un
enfriamiento ms localizado, o tratar de simplificar la infraestructura de
refrigeracin. Los bastidores de equipos de red, almacenamiento y servidores
generalmente se colocan en una cmara de sobrepresin elevada, dispuestos en
forma alternada orientados hacia atrs, creando los llamados pasillos fros y
calientes. El aire fro es forzado hacia arriba en los pasillos a travs del suelo
tcnico, y los ventiladores de los servidores o chasis lo impulsan a travs del
servidor hacia la parte posterior. El aire caliente de la parte posterior se dirige (a
veces mediante el uso de deflectores) hacia la planta de enfriamiento para su
recirculacin. Esta configuracin bsica no es costosa, pero tambin puede crear
puntos calientes irregulares, ya sea debido a un enfriamiento desigual o la
mezcla de aire caliente y fro.

2.5 Los principales problemas del centro de datos

Las aplicaciones de centros de datos implican cada vez ms el acceso
conjuntos masivos de informacin, minera de datos (Data Mining) en tiempo
real y transmisin en streaming que imponen grandes exigencias a la
infraestructura de procesamiento, conectividad y almacenamiento. El acceso
eficiente a grandes cantidades de datos requiere no slo los sistemas de
archivos de alto rendimiento, sino tambin de tecnologas de almacenamiento,
tales como medios de almacenamiento de estado slido (SSD). La transmisin
de grandes cantidades de datos requiere de redes de alta velocidad y baja
latencia. En las aplicaciones en clster, la comunicacin entre procesos (IPC) a
menudo implica mensajes ms pequeos pero con requisitos de muy baja
latencia.

Estas aplicaciones tambin pueden usar memorias principales remotas como

"cach" de la red de datos y as aprovechar las capacidades de red. Es mucho
menos costoso cargar procesos en la en la misma red fsica, como Ethernet, que
concentrarlos en un solo equipo. Sin embargo, esto requiere de capacidades
QoS sofisticadas que no estn necesariamente disponibles en los protocolos
existentes.

La Gestin de la configuracin es un componente vital para el buen

funcionamiento de los centros de datos, pero no ha recibido mucha atencin en
la literatura. Se requiere gestin de la configuracin en mltiples niveles, que
van desde los servidores a las troncales de interconexin para todo el centro de

8
datos. Los entornos virtualizados introducen temas de gestin de la
configuracin a un nivel lgico (en lugar de fsico). A medida que la
complejidad de servidores, entornos operativos y las aplicaciones aumenta, la
gestin eficaz en tiempo real de grandes centros de datos heterogneos se hace
muy compleja. Estos desafos y algunos enfoques actuales se discutirn
posteriormente.

Figura 5. La Gestin de Recursos en Centros de Datos

El aumento del tamao de los centros de datos no slo se traduce en altos

costos de servicio, sino que tambin conduce a importantes desafos en la
gestin energtica y trmica. Se estima que el consumo de energa total de los
centros de datos, como porcentaje del consumo total de energa de EE.UU. se
duplic entre 2000 y 2007, y se duplicar de nuevo en 2013. Los altos costos de
servicios pblicos y el impacto ambiental de este aumento son razones
suficientes para abordar el consumo de energa. Adicionalmente, el consumo
elevado de energa tambin se traduce en la corriente sostenible, la potencia, y
las densidades trmicas, y el uso eficiente del espacio del centro de datos. Tratar
los problemas energticos y trmicos requiere de tcnicas de control de potencia
y de refrigeracin en mltiples niveles (dispositivo, sistema, recinto, etc.) y a
travs de mltiples dominios (por ejemplo, hardware, sistema operativo y de
gestin). La gestin de la energtica y trmica tiene impactos considerables
sobre el rendimiento y por lo tanto se requieren esfuerzos para un tratamiento
combinado de potencia y el rendimiento.

Debido a que los los centros de datos aumentan de tamao y la criticidad, se

convierten cada vez ms en atractivos objetivos de ataque, por lo que una
vulnerabilidad aislada puede afectar a un gran nmero de clientes y / o
grandes cantidades de datos sensibles. As, un desafo a la seguridad

9
fundamental para los centros de datos es encontrar mecanismos viables que
permitan reducir el crecimiento de la vulnerabilidad conjuntamente con su
tamao. Bsicamente, la seguridad debe implementarse de forma que ningn
compromiso pueda proporcionar acceso a un gran nmero de mquinas o gran
cantidad de datos. Otra cuestin importante es que en un entorno virtualizado
y externalizado, ya no es posible hablar de "dentro" y "fuera" de los centros de
datos. Los intrusos podran muy bien ser los que comparten la misma
infraestructura fsica para sus fines comerciales.

Por ltimo, las propias tcnicas bsicas de virtualizacin aumentan las

vulnerabilidades desde la flexibilidad que ofrecen y ello puede ser aprovechado
fcilmente para la interrupcin y la denegacin de servicio. Por ejemplo,
cualquier vulnerabilidad en el mapeo de atributos de nivel VM para el sistema
fsico puede ser explotado para sabotear todo el sistema.

10
3 Evolucin de los Centros de Datos

Los centros de datos tradicionales han evolucionado como grandes

instalaciones computacionales y operados por una sola entidad nica,
comercial o no. Sin embargo, las fuerzas en juego se han traducido en que los
centros de datos se mueven hacia escenarios de propiedad mucho ms
complejas.

Por ejemplo, al igual que la virtualizacin permite la consolidacin y ahorro

de costes en un centro de datos, la virtualizacin de los centros de datos podra
permitir a un nivel mucho ms alto de agregacin. Esta idea lleva a la
posibilidad de "recursos externos" en centros de datos que permiten a una
organizacin para operar un gran centro de datos sin tener que poseer
infraestructura fsica. La computacin de la nube, de hecho, proporciona
exactamente tal capacidad, excepto que en la nube, los recursos se obtienen
generalmente de forma dinmica por perodos cortos y la gestin subyacente de
estos recursos est totalmente oculta para el usuario. Los suscriptores de los
centros de datos virtuales suelen solicitar acuerdos a ms largo plazo y mucho
ms control sobre la infraestructura de la que se les ofrece.

A continuacin se presenta un modelo conceptual de 4 capas para futuros

centros de datos que resume una amplia gama de implementaciones de centros
de datos emergentes. En esta representacin, los rectngulos se refieren a capas
de software y elipses se refieren a las abstracciones resultantes.

La capa inferior en este modelo conceptual es la capa de infraestructura fsica

(PIL) a menudo conocida como "granja de servidores", instalada en una
localizacin dada. Debido al aumento del costo de la energa consumida, el
espacio ocupado y el personal de gestin que se requiere, estas granjas de
servidores se estn observando cada vez ms cerca de las fuentes de
electricidad, agua, suelo y mano de obra menos costos. Estos lugares son, por su
naturaleza, ubicados geogrficamente en reas de baja demanda de servicio, y
por lo tanto la evolucin de las redes de ultra alta velocidad en largas distancias
son habilitadores esenciales de estas granjas de servidores ubicados
remotamente. Adems de la gestin fsica del hardware de computacin, la PIL

11
puede permitir la consolidacin a gran escala, proporcionando capacidades
para labrar secciones bien aisladas de la granja de servidores (o "parches de
servidores") y asignarlos a diferentes clientes. En este caso, el PIL ser
responsable de la gestin de las fronteras en todo el parche del servidor en
trminos de seguridad, cortafuegos, y la reserva de ancho de banda de acceso.
Por ejemplo, la configuracin y la gestin de redes LAN virtuales se realiza a
travs de la PIL.

La siguiente capa es la capa de infraestructura virtual (VIL) que aprovecha

las capacidades de virtualizacin disponible en distintos servidores, redes y
elementos de almacenamiento para apoyar la idea de un grupo virtual, es decir,
un conjunto de nodos virtuales o reales, junto con los caminos controlados de
calidad de servicio para satisfacer sus necesidades de comunicacin. En muchos
casos, la VIL ser interna a una organizacin que ha alquilado un parche
completo de servidores fsicos para ejecutar su negocio. Sin embargo, tambin
es concebible que los servicios VIL se encuentren en realidad bajo el control del
proveedor de la infraestructura que presenta efectivamente una abstraccin del
parche de servidor virtual para sus clientes. Esto es similar a la computacin en
nube, salvo que el suscriptor de un parche de servidores virtuales esperara
acuerdos de nivel de servicio (SLAs) explcitos en trminos de computacin,
almacenamiento e infraestructura de red asignados y necesitara visibilidad
suficiente para proporcionar su propia gestin del nivel requerido para el
funcionamiento de servicios mltiples o aplicaciones.

Figura 6. Modelo de Conceptual de Capas : Infraestructura Virtual e Infraestructura Fsica

La tercera capa en el modelo es la capa de la Coordinacin de Infraestructura

Virtual (VICL) cuyo objetivo es atar los parches del servidores virtuales en

12
varias granjas de servidores fsicos con el fin de crear un centro de datos
virtualizado distribuido geogrficamente (DVDC). Esta capa debe definir y
gestionar las tuberas virtuales entre distintos centros de datos virtuales. Esta
capa tambin sera responsable de la ubicacin geogrfica a travs del
despliegue, la ejecucin y la migracin de las aplicaciones, cada vez que sea
necesario. En funcin de sus capacidades, VICL podra ser explotado para otros
fines, tales como la reduccin de los costos de energa al distribuir la carga a
travs de husos horarios y tarifas de servicios pblicos, proporcionando
recuperacin ante desastre o gran escala de tolerancia a fallos, e incluso
permitiendo clculos distribuidos verdaderamente grandes.

Por ltimo, la capa de proveedor de servicios (SPL) es responsable de la

gestin y ejecucin de aplicaciones en el DVDC construidas por el VICL. El SPL
requiere de visibilidad sustancial de la configuracin fsica, el rendimiento, la
latencia, disponibilidad y otros aspectos de la DVDC para que pueda gestionar
las aplicaciones eficazmente. Se espera que SPL sea propiedad del cliente
directamente.

El modelo expuesto contempla todo, desde un centro de datos de nica

ubicacin, no virtualizado y enteramente en propiedad de una sola
organizacin; hasta uno distribuido geogrficamente (entro de datos totalmente
virtualizado) donde cada capa tiene posiblemente un propietario
independiente. Este ltimo extremo no solo proporciona una serie de ventajas
en trminos de la consolidacin, agilidad y flexibilidad, sino que tambin
plantea una serie de retos difciles en trminos de seguridad, definicin de SLAs
y el cumplimiento, la eficacia y los problemas de separacin de capas.

13
4 Infraestructura de Red en Centros de Datos

La creciente complejidad y sofisticacin de las aplicaciones de centros de

datos exige nuevas caractersticas de las redes. Para las aplicaciones en clster,
los servidores necesitan a menudo intercambiar mensajes de comunicacin
entre procesos (IPC) para la sincronizacin e intercambio de datos, y estos
mensajes pueden requerir de muy baja latencia para reducir la espera de
procesos.

La comunicacin directa entre servidores tambin puede estar motivada por

la baja latencia de acceso a los datos que residen en la memoria de otro servidor
en lugar de recuperarlo del almacenamiento secundario local. Por otra parte, la
mezcla de diferentes tipos de datos en el mismo tejido de red puede requerir
mecanismos de QoS para el aislamiento del rendimiento. Estos requisitos han
dado lugar a una considerable actividad en el diseo y el uso de entramados de
baja latencia en centros de datos especializados. Vamos a examinar algunos de
estos desarrollos en las siguientes secciones antes de examinar los desafos de
red en centros de datos.

4.1 El stack Ethernet

Dado que el stack Ethernet es bastante conocido, solo mencionaremos
algunos de sus puntos ms importantes en relacin con el entorno del centro de
datos.

La capa Ethernet es crucial en los centros de datos principalmente porque en

una infraestructura tpica se pueden encontrar ms conmutadores de Nivel 2
(switches) que enrutadores (Nivel 3). Esto tiene como resultado un costo
mucho menor, en funcin de la latencia y la sencillez de configuracin de un
conmutador de Nivel 2 en comparacin con un router. Sin embargo, esto podra
implicar que aquello que la capa IP puede hacer razonablemente bien (por
ejemplo, enrutamiento, QoS, filtrado, y seguridad) no est eficazmente
configurado en un centro de datos. Por otra parte, si tuviramos que
simplemente poner en prctica todos estos mecanismos en el Nivel 2
directamente, los conmutadores se volveran tan complejos, lentos y difciles de
configurar y administrar como los routers.

Una capacidad nica introducida en la red Ethernet en el estndar IEEE

802.1q es la nocin de virtual LAN o VLAN. El mecanismo de VLAN permite

14
que el trfico se identifique con una VLAN ID de 12 bits. En un caso de
asignacin esttica simple, las VLAN ID son estticamente asignadas a los
puertos del switch. Esto permite que las VLAN puedan proporcionar un fuerte
aislamiento en el trfico que pertenece a una VLAN y no pueda ser dirigido a
los puertos que no estn asignadas a esa VLAN. Existe tambin un esquema de
asignacin dinmica que puede asignar una VLAN a un conjunto nico de los
puertos en funcin de la direccin MAC de origen o de otros atributos del
trfico.

Figura 7. Ubicacin del Etiquetado VLAN en una trama Ethernet

Dado un conjunto extremos de Nivel 2 (por ejemplo, servidores o

enrutadores) conectados a travs de una red de conmutadores, un mecanismo
de enrutamiento Nivel 2 es esencial para proporcionar una entrega de baja
latencia de tramas Ethernet sin ningn tipo de bucles o de configuracin
compleja. El diseo original del Nivel 2 de enrutamiento se centr
principalmente en evitar los bucles de mediante la definicin de un nico rbol
de expansin para cubrir todos los puntos finales y los conmutadores. Este
protocolo Spanning Tree o STP (descrito en la norma IEEE 802.1D) desactiva
todas las conexiones que no son parte del rbol de expansin y por lo tanto su
ancho de banda disponible se desperdicia.

Adems, la estructura de rbol se traduce en una distribucin de trfico muy

desigual en los enlaces utilizados. Varias mejoras se han hecho para 802.1D para
abordar estos temas, incluyendo (a) Per VLAN Spanning Tree para que sea
posible utilizar un subconjunto diferente de enlaces para cada VLAN y por lo
tanto hacia fuera del trfico, (b) Rapid STP (RSTP) que detecta rpidamente
enlaces cados y reconfigura el rbol de expansin para reducir al mnimo
prdida de tramas, y (c) Multiple STP (MSTP), que utiliza varios rboles
"regionales" conectados a travs de un rbol de expansin superior central
(CST). Otras formas de utilizar varios rboles incluyen: (a) cada puerto del
switch acta como la raz del rbol de expansin para el trfico entrante a ese
15
puerto, y (b) Trfico de direccin de la misma fuente, entre varios rboles de
acuerdo con algunos criterios. A pesar de estos mecanismos, equilibrar el trfico
entre los diferentes eslabones an podra ser un reto.

Respecto de la QoS, los mecanismos de Ethernet comenzaron siendo bastante

primitivos, pero se han mejorado posteriormente. En particular, el mecanismo
de VLAN tambin incluye un campo de 3 bits para CoS (clase de servicio) en la
cabecera Ethernet extendida para diferenciar los flujos de VLAN. Este campo
puede ser explotado por el centro de datos Ethernet para diferenciar entre los
diferentes tipos de trfico (por ejemplo, almacenamiento vs comunicacin entre
procesos vs cliente - servidor).

El grupo de trabajo de IEEE sobre la gestin de la congestin Ethernet,

conocido como 802.1Qau, est estudiando la forma de mejorar la notificacin y
la gestin de la congestin. Los principales objetivos de esta iniciativa es
ayudar a los switches para marcar los paquetes y permitir al extremo de Nivel 2
hacer el control de flujo 802.1x a nivel de clases individuales de CoS. (El control
de flujo Ethernet predeterminado sucede en el nivel de enlace en su totalidad y
por lo tanto no es muy til cuando se tratan mltiples tipos de trfico.)

Aunque la capa IP proporciona un amplio conjunto de mecanismos de

control de calidad de servicio, aade latencia adicional significativa tanto en los
enrutadores y en los puntos finales. Del mismo modo, la interfaz tradicional
TCP sockets puede incurrir en grandes latencias especialmente con las
implementaciones tradicionales basadas en el ncleo.

La adopcin de la arquitectura VI (IPv6) junto con el apoyo de hardware

necesario puede reducir las latencias de extremo a extremo bajo en el rago de
10s, pero esto an no puede satisfacer las nuevas aplicaciones de minera de
datos y el modelado de datos financieros en tiempo real que requieren latencias
tan bajo como 1 s. Las interfaces de red que soportan RDMA pueden reducir
las latencias aun ms. Una de las dificultades en la aplicacin de RDMA a
travs de TCP es la necesidad de una capa intermedia llamada AMP para cerrar
la brecha entre la naturaleza de flujo de bytes TCP y transferencia orientada
mensaje esperado por RDMA.

La principal ventaja de la pila de Ethernet es la interfaz TCP / UDP a travs

de la cual la mayora de las aplicaciones operan. Sin embargo, TCP fue
diseado para un entorno de Internet abierta muy variable, y tiene numerosas

16
deficiencias desde una perspectiva de centro de datos. En particular, es bien
sabido que el logro de una buena calidad de servicio es muy difcil con TCP ya
que mltiples flujos TCP que compiten tendern a dividir el ancho de banda
disponible igualmente, en vez de hacerlo de acuerdo a las fracciones
especificadas. Del mismo modo, el control de congestin TCP puede ser
innecesariamente pesado para los centros de datos. En particular, TCP ofrece
esquemas elaborados para hacer frente a las prdidas de paquetes, que rara vez
se presentan en los centros de datos bien configurados. Las prdidas de
paquetes tambin pueden ser altamente indeseables a altas velocidades en las
que pueden degradar sustancialmente el rendimiento de la aplicacin. Las
implementaciones TCP basadas en retraso, tales como TCP-Vegas son mucho
ms apropiados para los centros de datos, pero estas versiones no son muy
populares.

TCP tambin sufre de otros puntos dbiles que se han tratado por otros
protocolos compatibles como SCTP (protocolo de transmisin de control de
stream). SCTP surgi de la necesidad de emular capacidades en el Internet en
el sistema de sealizacin N 7 (SS7). Aunque SCTP es un protocolo an ms
pesado que el TCP y por lo tanto puede ser difcil de escalar a altas velocidades,
ofrece un nmero de caractersticas que pueden ser tiles en los centros de
datos. Estas incluyen:

1. Multi-homing, que permite a una conexin usar rutas alternativas en caso

de fallo de ruta principal.

2. Mejor resistencia contra ataques de denegacin de servicio (DoS) al

retrasar la asignacin de memoria para la informacin de conexin y las
verificaciones de tipo reto-respuesta. En particular, SCTP no sufre del conocido
"ataque SYN" de TCP.

Figura 8. Flujo de Informacin del Protocolo SCTP

17
 3. Mejor robustez debido al CRC de 32 bits (frente a 16 bits para TCP) y una
funcin de mecanismo heartbeat. A altas velocidades de datos de 16 bits, CRC
puede dar lugar a errores no detectados con bastante frecuencia.

4. Extensibilidad del Protocolo a travs del mecanismo de "fragmento", que

permite la introduccin de nuevos tipos de mensajes de control.

5. La preservacin de los lmites de mensaje de capa superior, lo que

simplifica la implementacin RDMA.

6. Ms flexible entrega (ordenada o desordenada, y control sobre el nmero

de retransmisiones). Por ejemplo, la entrega ordenada es necesario para
RDMA.

SCTP tambin es compatible con el concepto de un "stream", que es un flujo

lgico dentro de una conexin con sus propias restricciones de orden de
paquetes. El concepto de stream permite tipos de datos diferentes pero
relacionados entre s que se transmiten semi-independiente, sin tener que crear
y gestionar mltiples conexiones. Desafortunadamente, la mayora de las
implementaciones de SCTP no optimizan esta funcin.

4.2 Desafos de las Redes en Centros de Datos

En esta seccin, se identifican los requisitos de red impuestas por la
evolucin de los centros de datos y, a continuacin exponemos las deficiencias
de entramados disponibles, de acuerdo a los requisitos.

En la idea de los centros de datos virtualizados distribuidos (DVDC)

discutido en el Captulo 3, se intenta crear la abstraccin de un nico centro de
datos que podran ser distribuidos geogrficamente. Si bien esto es una
abstraccin til, es crucial tomar ventaja de la estructura de 2 niveles situada
debajo: alto ancho de banda y baja latencia, comunicacin casi libre de errores
dentro de un parche de servidores fsicos, y mucho mayor latencia y entorno de
comunicacin de baja velocidad entre los centros de datos. En particular, a
nivel de middleware, la asignacin de recursos y la migracin deben tener en
cuenta de forma automtica para esta discrepancia. Del mismo modo, en el
nivel de transporte los protocolos deben ser de ajuste automtico y capaz de
trabajar bien tanto para los caminos que se mantienen completamente dentro de
un parche de servidores y los que van a travs de parches diferentes.

Dado que las comunicaciones intra e inter parches de servidores tienen

18
caractersticas muy diferentes, dan lugar a desafos muy diferentes. Por
ejemplo, un control de flujo basado en el crdito simple es apropiada para las
comunicaciones intra parches de servidores porque ofrece pequeos tiempos de
ida y vuelta (RTT), mnima prdida de paquetes, y un uso muy bajo de CPU.
Por otro lado, para las comunicaciones inter parches de servidores, un buen
rendimiento bajo prdida de paquetes debido a la congestin o los errores es
muy importante, y por lo tanto un control sofisticado (como en TCP o SCTP)
pueden ser necesarios.

Aunque se espera que las tecnologas de red de cable (cobre y/o fibra) de
permanecern dominantes en los centros de datos, las tecnologas inalmbricas
como Wi-Fi, ultra-ancha (UWB) y transmisiones pticas en el espacio libre estn
encontrando nichos para su aplicacin a medida que aumenta el ancho de
banda disponible. Por ejemplo, el ancho de banda inalmbrica disponible
puede ser adecuados para centros de datos de gama baja que ejecuten
aplicaciones de clculo intensivo. Incluso en los centros de datos ms grandes,
la tecnologa inalmbrica puede resultar muy adecuada como para una red de
gestin. Las tecnologas inalmbricas tienen la importante ventaja de eliminar el
problema de gestin de cables, para permitir la adicin/supresin de la
infraestructura, y proporcionar un medio de comunicacin de difusin (a
diferencia de punto a punto) que puede ser explotado de manera inteligente.

Para apoyar esta diversidad en capas MAC, debera ser posible elegir el
mecanismo de control de congestin en funcin de las capas atravesadas. Para
un protocolo orientado a conexin, el control de la congestin puede ser
negociado durante el establecimiento de la conexin, sin embargo, en algunos
casos, los ajustes dinmicos automatizados pueden tambin ser necesarios.

A medida que la tecnologa en capas MAC evoluciona, se est logrando

obtener velocidades de datos sin precedentes. Por ejemplo, un enlace de 12X
GEN3 IBA puede soportar anchos de banda de 120 GB/s. Ethernet de 100 GB/s
se encuentra en fases finales de desarrollo.

En 100 GB/s, un tamao promedio de 1.000 paquetes byte debe ser

procesado en menos de 80 ns. Con un protocolo complejo, es muy difcil de
completar el procesamient en capas MAC, transporte y red en 80 ns, en
particular cuando se trata de accesos a memoria. Est claro que en ltima
instancia, los reductores de velocidad de la red estarn limitados por el

19
fenmeno llamado "memoria-wall". Por lo tanto, adems de la colocacin
directa de los datos en las memorias cach, es necesario ir ms all de la
arquitectura VI y hacer que los protocolos sean tan ligeros como sea posible.
Ello va directamente ligado una mayor funcionalidad necesaria para hacer
frente a la seguridad, la flexibilidad y otras cuestiones. A tasas muy altas de
datos, toda la pila de protocolos incluyendo MAC, las capas de red y transporte
deben ser tratadas. Esto puede plantear problemas importantes en el
mantenimiento de la compatibilidad con las normas.

La arquitectura tradicional de red en rbol proporciona una seccin

transversal de ancho de banda limitado que podra convertirse en un problema
en los grandes centros de datos. Este problema puede ser abordado mediante el
uso de muchos ms switches, pero de menor capacidad, en los niveles
superiores de la jerarqua en una topologa CLOS o fat-tree. Un problema con
este enfoque es el aumento en el nmero de activos que deben gestionarse.
Algunos autores se encargan del impacto introducido por el protocolo de
Spanning Tree utilizando un gestor de entramado centralizado para toda la
red. Este gestor de entramado utiliza ubicacin jerrquica basada en
direcciones pseudo-MAC para controlar el enrutamiento mientras que los
switches de borde traducen entre estas direcciones y las reales.

Otros enfoques son tambin explorados, en donde los conmutadores

Ethernet estndar se sustituyen por nuevos tipos de switches llamados "Axons"
a los que son conectados los equipos Ethernet sin modificaciones. Los axones
utilizan enrutamiento de origen en base a la tabla de enrutamiento en el Axon
entrada. El mantenimiento de la tabla de enrutamiento se realiza por software
que se ejecuta en el procesador Intel Atom, y el enrutamiento real se realiza
en hardware usando el FPGA. Otro intento de este tipo llamado Ethane
proporciona un control centralizado sobre toda la red. Debe tenerse en cuenta
que las soluciones de control centralizadas pueden ser vulnerables a fallos y
ataques; y pueden tener problemas de escalabilidad.

En el Captulo 3 se introdujo el concepto de clster virtual (VC), el cual

requiere de aprovisionamiento rutas de comunicacin controladas mediante
QoS entre los nodos virtuales. Para permitir esto, es necesario etiquetar todas
las comunicaciones dentro de un clster virtual de modo que sea posible
diferenciar entre varios clsteres virtuales que comparten las mismas rutas de
comunicacin. Adems, es necesario pensar en calidad de servicio en trminos

20
de las necesidades de toda la aplicacin, ms que en las necesidades de un flujo
individual entre dos puntos finales. Esta es la principal diferencia entre el tipo
de QoS que se aqu se discute, y las nociones tradicionales de QoS. Las
etiquetas pueden ser utilizadas para garantizar que los clusters virtuales que
compiten en una ruta de acceso compartido son provistos de ancho de banda,
ya sea de acuerdo con algunos criterios fijos (por ejemplo, prioridad relativa o el
tipo de aplicacin que se ejecuta en el clster virtual) o basarse en los cambios
dinmicos de las necesidades de las aplicaciones. Una forma de estimar la
necesidad de ancho de banda dinmico es hacer un seguimiento del uso de
ancho de banda real durante los perodos sin congestin y luego dividir el
ancho de banda disponible en esa proporcin durante los perodos de
congestin.

El etiquetado y control de ancho de banda correspondiente se pueden

implementar en los distintos niveles de la pila de red con diferentes
consecuencias. El etiquetado en el nivel MAC (Nivel 2) asegura de que los
switches pueden participar en la gestin de etiquetas y el ancho de banda
provisto. El proyecto de centro de datos en Ethernet del IEEE se ocupa
bsicamente de aprovechar los tres bits existentes de CoS (Class of Service) en la
trama Ethernet para etiquetado y gestin de ancho de banda.

Figura 9. Bits de Clase de Servicio en una Trama Ethernet

La expansin de este mecanismo a los clsteres virtuales en toda regla

requerira perturbaciones importantes en el estndar Ethernet existente y
todava requerira un mecanismo en la capa IP para manejar grupos virtuales
que van a travs de capa 2. En la capa 3, MPLS (Multi-Protocolo Label
Switching) ya proporciona mecanismos sofisticados para flujos etiquetados y
los mecanismos de reserva de recursos correspondientes, tales como RSVP-TE
se pueden utilizar para automatizar la configuracin. Estos pueden ser usados
para la configuracin de caminos entre parches de servidores, pero no son tiles

21
dentro de un centro de datos debido a la abundancia de switches de Nivel 2.

Por ltimo, el etiquetado en la capa de transporte es fcil de implementar,

pero slo tendr importancia variable. Es decir, mientras que las etiquetas se
pueden utilizar para el control de la congestin de las conexiones que
pertenecen a diferentes grupos virtuales, no se repercute su aplicacin en la
propia red. Algunos autores proponen un mecanismo de marcado junto con la
nocin de control de ancho de banda colectiva que determina de forma
automtica las necesidades de las cargas de trabajo que compiten entre si, y los
intentos de asignar ancho de banda proporcional durante congestiones. En
general, un control preciso sobre ancho de banda proporcionada a las
aplicaciones puede ser bastante difcil con TCP como mecanismo de control de
congestin.

En un entorno virtualizado, la comunicacin entre los nodos necesita un

mecanismo para detectar automticamente cuando dos nodos se encuentran en
la misma plataforma y por lo tanto se pueden comunicar sin la participacin de
la red externa. Los recientes avances como XenLoop proporcionan un
mecanismo transparente para interceptar automticamente los paquetes de
mquinas virtuales co-residentes y los coordinar a travs de la interfaz de
memoria compartida. Un tema similar se plantea para la comunicacin local
frente a no-local. Por ejemplo, si el entramado intra-chasis es diferente del
principal (por ejemplo, PCI-Express vs Ethernet), puede ser necesario cambiar
de forma transparente entre protocolos de transporte apropiados para los
medios de comunicacin. Proporcionar un mecanismo de comunicacin de bajo
overhead y transparente entre VM's que se pueden migrar de forma
dinmica, as como el soporte de hardware, sigue siendo un problema difcil.

Mientras los centros de datos se mueven de entidades fsicas en propiedad al

modelo DVDC discutido previamente, se hace mucho ms difcil protegerlos
contra la denegacin de servicio y otros tipos de ataques. Por lo tanto, los
mecanismos de seguridad tales como los adoptados por SCTP se han
convertido en algo esencial, a pesar de su considerable overhead. El gran reto
es garantizar la escalabilidad de estos mecanismos de proteccin a tasas muy
altas de transmisin de datos que pueden ser vistos en el futuro. Del mismo
modo, el apoyo a mecanismos de alta disponibilidad tales como multi-homing,
la migracin de conexin, la diversidad y el control de rutas se han convertido
en algo crtico en este entorno; sin embargo, la bsqueda de soluciones

22
escalables para ellos puede ser muy difcil.

Las redes de centros de datos a menudo despliegan una variedad de

dispositivos de red o middle-boxes, como lo son servidores de nombres de
dominio (DNS), firewalls, balanceadores de carga, traductores de direcciones de
red (NAT), gateways de redes privadas virtuales (VPN), aplicaciones de
escaneo de malware, aceleradores de protocolo, etc. La implementacin,
configuracin, ingeniera de trfico, y mantenerlos actualizados es a menudo
una tarea muy difcil y sigue aumentando en complejidad a medida que crecen
los centros de datos, pero no ha recibido mucha atencin en la literatura. La
gestin de estos dispositivos en un entorno DVDC puede ser particularmente
difcil, puesto que los propios cuadros intermedios pueden necesitar ser
virtualizados sin comprometer la seguridad, el aislamiento y las caractersticas
de rendimiento que estn destinados a proporcionar.

4.3 VXLan : Superando el lmite de VLans

La virtualizacin de servidores ha generado una mayor demanda sobre la
infraestructura de la red fsica. Como mnimo, hay una necesidad de ms
entradas de la tabla de direcciones MAC a lo largo de la red de conmutacin
Ethernet debido a la potencial agregacin de cientos de miles de mquinas
virtuales (VM), cada una con su propia direccin MAC.

En segundo lugar, las mquinas virtuales pueden ser agrupadas de acuerdo

a su LAN virtual (VLAN) funcional. Un centro de datos puede necesitar miles
de VLANs para dividir el trfico de acuerdo con el grupo funcional especfico al
que la mquina virtual puede pertenecer. El lmite actual de 4094 VLANs es
insuficiente en situaciones ya presentes en los centros de datos. Uno de los
requisitos relacionados con los entornos virtualizados es balancear trfico en
Nivel 2 a travs de todo el centro de datos o incluso entre varios centros de
datos para la asignacin eficiente de recursos de computacin, recursos de red y
almacenamiento. Utilizar enfoques tradicionales como Spanning Tree Protocol
(STP) para una topologa sin bucles puede resultar en un gran nmero de
enlaces limitados en capacidad en entornos de alta densidad.

Otro tipo de demanda que se est generando en los centros de datos es la

necesidad de alojar mltiples sistemas huspedes, cada uno con su dominio de
red aislada. Esto no resulta econmico utilizando infraestructura dedicada, por
lo que los administradores de red optan por implementar una red compartida.

23
Un problema recurrente es la asignacin independiente de direcciones MAC y
VLAN ID que conducen a la potencial duplicacin de estas en la red fsica.

El ltimo escenario es el caso en que el operador de la red prefiere utilizar IP

para la interconexin de la infraestructura fsica (para lograr escalabidad a
travs de multitrayecto con igualdad de costo [ECMP]) y al mismo tiempo
conservar el modelo de Nivel 2 para la comunicacin inter-VM.

Los escenarios descritos anteriormente conducen a la exigencia de una red

superpuesta. Esta red se utilizara para transportar el trfico MAC desde las
VMs individuales en un formato encapsulado sobre un "tnel" lgico.

Figura 10. Ubicacin del Campo VXLAN ID (24 Bits)

VXLAN (Red de rea Local Virtual Extensible) aborda los requisitos de la

infraestructura de red de centro de datos en presencia de mquinas virtuales en
un entorno multiusuario. Se ejecuta a travs de la infraestructura de red
existente y proporciona un medio para "ampliar" la redes de Nivel 2. En
resumen, VXLAN es un esquema de superposicin de Nivel 2 en una red de
Nivel 3. Cada capa de superposicin o overlay se denomina segmento
VXLAN. Slo las mquinas virtuales en el mismo segmento VXLAN pueden
comunicarse entre s. Cada segmento VXLAN es aislado en mbito de
operacin a travs de un ID de segmento de 24 bits, en adelante denominado el
identificador de red VXLAN (VNI). Esto permite hasta 16 millones de
segmentos VXLAN dentro del mismo dominio administrativo.

VNI reconduce cada trama de MAC interna originada por la mquina virtual
individual. Por lo tanto, podra haber superposicin o solapamiento de
direcciones MAC a travs de segmentos, pero nunca tener trfico cruzado entre
ellos, ya que el trfico es aislado utilizando el identificador VNI. Este
identificador se encuentra en un encabezado exterior a la trama MAC interno
originada por la VM. En lo sucesivo, el trmino "segmento VXLAN" se usa de
manera intercambiable con el trmino "red superpuesta VXLAN."

Debido a esta encapsulacin, VXLAN tambin podra denominarse como un

esquema de tunelizacin para superponer las redes de Nivel 2 sobre redes de

24
Nivel 3. Los tneles son stateless, as que cada trama se encapsula segn un
conjunto de reglas. El punto final del tnel (VTEP) se encuentra dentro del
hipervisor en el servidor que aloja las mquinas virtuales. As, el VNI y el tnel
VXLAN, conjuntamente con la cabecera, son visibles nicamente a al VTEP (la
mquina virtual no lo ve). Los VTEPs tambin podran encontrarse en un
switch o servidor fsico y podran ser implementados en software o hardware.

A continuacin se examinan escenarios tpicos de flujo de trfico en un

entorno VXLAN utilizando un tipo de esquema de control aprendizaje del
plano de datos. En estos casos, la asociacin de MAC de las VMs a las IP de los
VTEP es descubierta a travs de aprendizaje del origen. Se utiliza Multicast
para llevar tramas con destino desconocido, as como tramas de broadcast y
multicast.

En adicin a un plano de control basado en el aprendizaje, hay otros

esquemas posibles para la distribucin de las asociaciones de la IP del VTEP a
las MAC de VMs. Estas opciones podran incluir una bsqueda en un
directorio central realizada por los VTEPs individuales; o la distribucin directa
de esta informacin de mapeo hacia los VTEPs por el directorio central. Estas
opciones son a veces caracterizadas como modelos de push y pull.

A continuacin se muestra el formato de trama VXLAN. Al analizarla desde

la parte inferior, observamos la trama de MAC interior conjuntamente con su
cabecera Ethernet con las direcciones MAC de origen y destino, junto con el tipo
de Ethernet ms una VLAN opcional. Un caso de uso de la etiqueta interior de
VLAN es el etiquetado VLAN basado en VM, en un entorno virtualizado.

Figura 11. Encapsulamiento del encabezado VXLAN

La trama MAC interior se encapsula con las siguientes cuatro cabeceras (a

partir de la cabecera ms interna) :

1. Cabecera VXLAN : Este es un campo de 8 bytes que contiene los siguientes

25
 - Banderas (8 bits) : Donde la bandera I debe establecerse en 1 para un ID
de red VXLAN vlido. Los otros 7 bits (designados "R") son campos reservados
y se deben establecer en cero.

- ID de Segmento VXLAN/Identificador de Red VXLAN (VNI) : Este es

un valor de 24 bits utilizado para designar la red superpuesta de VXLAN en la
que la que se encuentran las VMs que estn comunicndose. Las VMs en
diferentes VXLAN no pueden comunicarse entre s.

- Campos reservados (24 bits y 8 bits) - se deben establecer en cero.

2. Cabecera UDP exterior : Esta es la cabecera UDP exterior con un puerto de

origen proporcionado por el VTEP conjuntamente con el puerto de destino,
siendo ste ltimo un puerto bien conocido. IANA ha asignado el valor 4789
para el puerto UDP VXLAN. Este valor debe ser usado por defecto como el
puerto UDP de destino.

Algunas implementaciones iniciales de VXLAN han utilizado otros valores

para el puerto de destino. Para habilitar la interoperabilidad con estas
implementaciones, el puerto de destino debe ser configurable. Se recomienda
que el nmero de puerto de origen sea calculado mediante un hash de los
campos del paquete interno; como por ejemplo un hash de los encabezados de
tramas Ethernet internas. Esto es para permitir un nivel de entropa para
balanceo de carga/ECMP de la mquina virtual para el trfico entre VMs a
travs de la VXLAN.

El campo checksum UDP debe transmitirse como cero. Cuando se recibe un

paquete con una suma de comprobacin o checksum igual a cero, ste deber
ser aceptado para ser desencapsulado. Opcionalmente, si el extremo
encapsulado incluye una suma de comprobacin diferente de cero, sta deber
ser calculada correctamente en todo el paquete, incluyendo el encabezado IP, el
encabezado UDP, encabezado VXLAN y la trama MAC encapsulada.

Cuando un punto final recibe un paquete con una suma de comprobacin no

nula puede optar para verificar el valor de suma de comprobacin. Si opta por
realizar la verificacin y sta falla, el paquete debe rechazarse. Si el destino
decide no realizar la verificacin o la realiza con xito, el paquete deber ser
aceptada para ser desencapsulado.

26
 3. Encabezado IP Exterior : Contiene la direccin IP de origien, indicando la
direccin IP del VTEP sobre el que se comunican las VMs (tal como lo
representan la direccin de MAC interna). La direccin IP de destino puede ser
unicast o multicast. Cuando es una direccin IP unicast, contiene la direccin IP
del VTEP que conecta a las VMs que estn comunicndose.

Tradicionalmente, las redes de Nivel 2 slo puede ser atacadas desde

"dentro" por los extremos implicados, ya sea por el acceso inadecuado a una
LAN, inspeccionando el trfico, o mediante la inyeccin de paquetes
falsificados para suplantar otra direccin MAC, o causando inundaciones del
tipo DoS. Un mecanismo de MAC-sobre-IP para la entrega de trfico de Nivel 2
extiende significativamente la superficie expuesta a ataques. Esto puede ocurrir
si los intrusos se inyectan a s mismos en la red mediante la suscripcin a uno o
ms grupos multicast que transportan trafico broadcast para segmentos
VXLAN. Del mismo modo, al originar tramas Mac-sobre-UDP en la red de
transporte para inyectar trfico espreo.

Los ataques de Nivel tradicionales realizados por puntos finales falsos

pueden ser mitigados mediante la limitacin del mbito de la gestin y
administracin de quien despliega y gestiona VMs en un entorno VXLAN.
Adems, las medidas administrativas ya disponibles pueden ser aumentadas
por esquemas como 802.1X para el control de admisin de los puntos finales
individuales. Tambin, el uso de encapsulacin basada en UDP de la VXLAN
permite la explotacin de la funcionalidad de Listas de Control de Acceso
(ACL) basada en 5 tuplas de los conmutadores o switches.

El trfico de tnel a travs de la red IP se puede asegurar con mecanismos de

seguridad tradicionales, como IPsec para la autenticacin y, opcionalmente el
cifrado del trfico VXLAN. Esto, por supuesto, deben complementarse con una
infraestructura de autenticacin para los puntos finales autorizados para
obtener y distribuir las credenciales.

Las redes VXLAN son designadas y operadas sobre la infraestructura LAN

existente. Para asegurarse de que los puntos finales VXLAN y sus VTEPs estn
autorizados en la LAN, se recomienda que las VLAN sean designadas para el
trfico VXLAN, y los servidores/VTEPs envien trfico VXLAN sobre esta
VLAN para proporcionar una medida de seguridad.

Adems, VXLAN requiere de una asignacin adecuada de VNIs y

27
pertenencia de VM en las redes superpuestas. Se espera que esta asignacin se
haga y se notifique a la entidad de gestin en el VTEP y las pasarelas utilizando
los mtodos existentes de seguridad.

28
5 Almacenamiento en los Centros de Datos

A pesar del enorme crecimiento en la capacidad de almacenamiento en la

ltima dcada, el tsunami de datos no muestra seales de disminuir; de hecho,
impulsado por las nuevas aplicaciones de gran escala, el crecimiento superior a
la Ley de Moore en la capacidad computacional y la expansin mundial
conectividad; el crecimiento del almacenamiento contina acelerndose.

De acuerdo con estimaciones del IDC, el volumen de datos sigue

aumentando 50-70% por ao. Estas tendencias hacen que la gestin de
almacenamiento en los centros de datos sea extremadamente desafiante. En
este Captulo ofrecemos una visin general de las tecnologas emergentes de
almacenamiento y las necesidades de las aplicaciones; para luego discutir los
principales desafos.

5.1 Conceptos bsicos de almacenamiento

Hasta hace poco, la mayor parte del almacenamiento utilizaba medios
magnticos de rotacin, y las arquitecturas de almacenamiento se desarrollaban
alrededor de esta tecnologa.

El almacenamiento en centros de datos puede tomar una las tres formas

siguientes, o una combinacin de ellas : almacenamiento adjunto directo (DAS),
red de rea de almacenamiento (SAN) y almacenamiento conectado a red
(NAS). DAS se refiere al almacenamiento orientado a bloques directamente
conectados a un servidor. SAN proporciona almacenamiento orientado a
bloques que se encuentran en una red. NAS tambin proporciona acceso al
almacenamiento que residen en una red, pero accesible a travs de una interfaz
de nivel superior, tales como archivos u objetos.

La tecnologa DAS dominante ha sido la unidad de disco duro desde hace

bastante tiempo y ha continuado escalando en su rendimiento. Sin embargo,
existen varias deficiencias inherentes a los discos duros que se estn volviendo
cada vez ms difciles de superar a medida que avanzamos en los diseos ms
rpidos y ms densos. En particular, el movimiento mecnico implica que los
discos seguirn siendo significativamente ms rpidos para los accesos
secuenciales que para accesos aleatorios, y esta brecha tiende a crecer.

Esto puede limitar severamente el rendimiento que los sistemas basados en

29
disco duro son capaces de ofrecer a las cargas de trabajo con componente de
acceso aleatorio significativo o falta de localidad. Aunque un disco duro actual
consume mucha menos energa que otros componentes de un servidor (por
ejemplo, aproximadamente 12 W frente a 150 W para el subsistema de
procesador), el gran nmero de dispositivos de almacenamiento se traduce en
que un 20 - 30 % de la energa del centro de datos podra ser consumida por el
almacenamiento.

La interfaz de almacenamiento secundario tradicional en el mundo de los

servidores ha sido SCSI (Small Computer System Interface). SCSI puede
manejar hasta 15 unidades de disco duro y altas tasas de transferencia. A pesar
de que una serie de 15 discos SCSI puede ofrecer una velocidad conjunta de
transferencia de datos elevada, incluso pequeas fracciones de patrones de
acceso aleatorio pueden degradar seriamente el rendimiento. Sin embargo, un
conjunto de 15 unidades de estado slido o hbrido podra superar fcilmente
este lmite, lo que implica la necesidad de interfaces ms rpidas.

La interfaz SCSI de conexin serie (SAS) ya est reemplazando la interfaz

SCSI tradicional paralela con una interfaz de enlace en serie. Con enlaces de 6
GB/s, una unidad SAS puede proporcionar velocidades de transferencia de
hasta 2,4 GB/s. Los clientes tradicionalmente han utilizado el interfaz ATA
paralela, que tambin estn siendo reemplazada por la versin de serie llamada
SATA.

Figura 12. Caractersticas de diversas Interfaces de Almacenamiento

Aunque el almacenamiento de conexin directa (DAS) en cada servidor

puede proporcionar un acceso ms rpido, tiene numerosas limitaciones en
cuanto al tamao y la flexibilidad. En consecuencia, la capacidad de
almacenamiento dentro del servidor es generalmente pequeo y reservado para
los datos locales, tales como la imagen de arranque y el espacio de intercambio.

30
El almacenamiento compartido generalmente se aprovisiona por separado en
una "torre de almacenamiento" y se accede a travs de NAS o SAN. NAS
proporciona un archivo conveniente o acceso a nivel de objeto para los
servidores y se puede utilizar el entramado de redes tradicionales, como
Ethernet. Sin embargo, el acceso de alto nivel puede ser demasiado lento o no
apto para aplicaciones que prefieren hacer su propia gestin de
almacenamiento (por ejemplo, los sistemas de base de datos). Tanto NAS y
SAN (se discute a continuacin) encuentran un lmite de almacenamiento entre
8 y 16 TB debido al direccionamiento de 32 bits utilizado en las
implementaciones.

SAN proporciona el acceso a nivel de bloque de almacenamiento remoto y se

ha utilizado tradicionalmente de canal de fibra (FC) como la tecnologa de red
preferida para su implementacin. Aunque FC est diseado especficamente
para el acceso al almacenamiento, la necesidad de una infraestructura de red
separada y el conocimiento limitado de los administradores hace que sea
costoso de operar y mantener. iSCSI (Internet SCSI) es una alternativa a la FC y
permite el acceso remoto a las unidades SCSI a travs de la conexin principal
Ethernet (la interfaz de hardware podra ser en serie o en paralelo, y no importa
en el nivel de protocolo). iSCSI normalmente se ejecuta sobre TCP y por lo
tanto es fcil de implementar, pero el uso de capas superiores puede resultar en
un significativamente menor rendimiento que FC. Este problema puede ser
parcialmente abordado por tarjetas iSCSI que implementan iSCSI y TCP/IP en
el hardware subyacente. La aparicin de Ethernet 10 GB/s de bajo coste
tambin ha hecho que iSCSI sea mucho ms atractivo.

Muchas aplicaciones que utilizan almacenamiento de acceso de bajo nivel

(por ejemplo, sistemas de gestin de bases de datos) estn diseados para el
almacenamiento FC. Por lo tanto, a pesar de una eventual tendencia a un iSCSI
mucho ms barato o soluciones basadas en Ethernet similares, las interfaces FC
sern utilizadas por bastante tiempo. Varios protocolos estndar han sido
diseados para la interconexin de FC y TCP/IP. El protocolo FCIP encapsula
FC paquete en los paquetes TCP para la transmisin a travs de una red IP. El
FCoE (FC over Ethernet) encapsula los paquetes FC en tramas Ethernet y por lo
tanto no se puede enrutar. El protocolo iFCP es una puerta de entrada al
protocolo de puerta de enlace que permite una transmisin directa de la carga
til del paquete FC travs de una red TCP/IP intermedia.

31
 En general, un volumen de almacenamiento puede propagarse a travs de
mltiples dispositivos de almacenamiento fsicos o lgicos, y una visin
consistente requiere de "virtualizacin del almacenamiento". La virtualizacin
del almacenamiento puede ser basado en host, basada en la red o en dispositivo
de almacenamiento. Una solucin basada en host ampliamente desplegada es
Logical Volume Manager (LVM) en el sistema operativo husped, el cual
maneja volmenes de almacenamiento repartidos en varios dispositivos bajo su
control. La virtualizacin basada en red realiza la misma tarea utilizando
algunos "aparatos" directamente conectados a la red de servidores. En una
versin ms sofisticada de este enfoque las rutas de datos y de meta-datos
pueden ir a travs de redes separadas. En an otra variacin, la funcionalidad
de virtualizacin puede estar integrada en el switch de SAN (tal vez usando
ASIC), de modo que el conmutador puede dirigir la solicitud al volumen de
almacenamiento adecuado y de ese modo reducir el nmero de saltos de la red.
Por ltimo, el dispositivo de almacenamiento en s puede proporcionar esta
funcionalidad. Con la mayora de estas soluciones, la virtualizacin se extiende
slo al alcance del agente de control (host OS, switch, etc) y la interoperabilidad
se hace difcil ya que los diferentes sistemas operativos, aplicaciones y
dispositivos de almacenamiento pueden implementar la virtualizacin de
forma diferente.

La unificacin de mltiples subsistemas de almacenamiento virtualizados

requiere una entidad de nivel superior para coordinar el acceso a travs de
estos subsistemas. Esta unificacin es requerida cada vez ms debido a las
limitaciones en espacio de almacenamiento tradicional NAS / SAN. Un ejemplo
muy conocido de esta coordinacin es el sistema de archivos en clster (CFS).
CFS se compone de una serie de "cabezas de grupo" cada uno de los cuales es
un servidor especializado que gestiona el almacenamiento bajo su control,
proporcionando una distribucin a travs del grupo de archivos y objetos, y
permitiendo el acceso transparente a los archivos y objetos almacenados en
cualquier lugar a travs de los nodos del clster. Funciones de almacenamiento
nominales como striping y mirroring deben ser proporcionados por el CFS en el
clster de manera transparente. CFS tambin tiene que ofrecer resiliencia frente
a los dispositivos de almacenamiento a travs de grupos que pueden
experimentar fallas. Algunos ejemplos de CFS, diseados para entornos HPC a
gran escala son, el sistema Lustre, el sistema de ficheros paralelo-virtual (PVFS)
y el sistema general de archivos paralelos de IBM (GPFS).

32
5.2 Almacenamiento en discos de estado slido e hbridos
La mejora continua en el coste y el rendimiento de almacenamiento basado
en memoria flash ha hecho de los discos de estado slido (SSD) una tecnologa
viable en los centros de datos. Por otra parte, existen otras tecnologas RAM
(NVRAM) que pueden alterar significativamente el paisaje de almacenamiento
en el futuro cercano. Algunas de las tecnologas ms prominentes incluyen
NVRAM RAM magntica (MRAM), la memoria de cambio de fase (PCM o
PRAM) y la RAM Ferro-elctrica (FeRAM). Las tecnologas NVRAM ofrecen
varias ventajas sobre los medios magnticos rotativos:. Latencias de acceso
inferiores y ms previsibles para las solicitudes al azar, factores de forma ms
pequeos, menor consumo de energa, la falta de ruido y mayor robustez a las
vibraciones y la temperatura. Puesto que la memoria flash NAND es el ms
maduro y popular de ellos en este momento, vamos a utilizar esta tecnologa
como representativa para conducir la discusin.

Figura 13. Memoria de Ncleo Magntico (a) y Ferro-Elctrica (b)

Comenzamos con algunas caractersticas de almacenamiento basado en flash.

Los dispositivos Flash requieren una operacin de borrado antes de que los
datos se pueden escribir, y ste borra slo puede realizarse en unidades de
bloques. Un bloque consta de 64 o 128 pginas. Una pgina es la granularidad
de lecturas y escrituras individuales, y es tpicamente de 2 KB de tamao. Una
operacin de borrado no slo es muy lenta (alrededor de 2 ms para bloque 128
K), sino que tambin da como resultado una ligera degradacin del flash,
limitando de este modo el tiempo de vida til de un bloque. Cada bloque tiene
tpicamente una vida de aproximadamente 100 K operaciones de borrado K.
Existen tcnicas de nivelacin de desgaste que distribuyen la ubicacin fsica
del bloque de tal manera que los borrados se extienden uniformemente a travs
de toda la memoria flash.

Cada pgina del flash puede estar en uno de tres estados diferentes: (i)
vlida, (ii) no vlido y (iii) libre / borrado. Cuando ningn dato se ha escrito en
una pgina, se encuentra en estado libre o borrado. Una escritura puede hacerse

33
slo a una pgina libre, cambiando su estado a vlido. Un recolector de basura
(GC) se ejecuta peridicamente e identifica los bloques que slo contienen
pginas no vlidas y las borra. Durante los perodos de GC, el rendimiento
ofrecido por un dispositivo de memoria flash puede disminuir
significativamente. La frecuencia de GC y sus gastos computacionales
empeoran con el aumento de la aleatoriedad en la escritura.

Por ltimo, las celdas de memoria flash pueden ser de un solo nivel (SLC) o
Multi-Level-Cell (MLC). Como el nombre implica, SLC almacena un bit por
celda y MLC almacena ms de uno. MLC proporciona una mayor densidad y
por lo tanto menor coste global, sin embargo, esto se produce a expensas de una
velocidad ms lenta, significativamente menor tiempo de vida, y menor
temperatura de funcionamiento (debido a la mayor probabilidad de errores
causados por la corriente de fuga a temperaturas ms altas). Por lo tanto, las
unidades de estado slido (SSD) utilizan invariablemente SLC, siendo MLC
ms comn en las aplicaciones de consumo tales como unidades flash.

Con el fin de mantener la compatibilidad con los discos duros, los SSD estn
diseados para utilizar interfaces de E/S estndar tales como buses de SCSI o
SATA. Un procesador integrado implementa la llamada Capa Traduccin Flash
(FTL) para ocultar la identidad del flash y lograr que el mismo software pueda
trabajar tanto con unidades de disco duro y SSD. La funcionalidad clave
implementada por el FTL incluye: (i) la traduccin de direcciones lgicas a
direcciones fsicas para permitir la nivelacin del desgaste, (ii) actualizaciones
fuera de rango y recoleccin de basura, y (iii) las polticas de nivelacin de
desgaste. La calidad de la ejecucin FTL es una clave para el rendimiento SSD,
por ejemplo, se ha determinado que para ciertas cargas de trabajo de escritura
realizadas al azar (por ejemplo, las cargas de trabajo de DBMS) los tiempos
empleados de GC y de nivelacin de desgaste a veces puede hacer a los SSDs
ms lentos que los discos duros. Para accesos secuenciales, los discos duros
pueden superar fcilmente los SSD. Sin embargo, los SSD tienen un gran
potencial para un rendimiento ms alto y ms predecible que los discos duros.

Aunque los SSD pueden ser tiles como medio independiente de

almacenamiento secundario para aplicaciones de alto rendimiento y baja
latencia, por lo general se espera que permanezcan en el rol de apoyo para los
discos duros en el futuro previsible. Muchos trabajos han explorado SSD como
una capa intermedia en la jerarqua de almacenamiento entre la memoria

34
principal y el disco duro de almacenamiento secundario. Sin embargo, muchos
otros problemas en la integracin de los SSD's y discos duros para un
rendimiento ms rpido y ms consistente an no se han resuelto.

Figura 14. Controlador de Memoria Flash

5.3 Desafos en el almacenamiento

Aunque la virtualizacin y agrupacin proporcionan mecanismos para
manejar grandes cantidades de almacenamiento, el cada vez mayor volumen de
datos almacenados seguir planteando problemas de escalabilidad en mltiples
niveles. La gestin de un gran nmero de dispositivos de almacenamiento (que
se puede dividir en varios grupos) no plantean importantes desafos en
trminos de rendimiento y disponibilidad. Otra cuestin se refiere a la gestin
eficiente de un gran nmero de objetos (como archivos) que se espera que un
sistema de almacenamiento de gran tamao pueda albergar.

Los tamaos de los objetos mismos podran variar en un amplio rango. En

particular, la distribucin de tamao de archivo Zipf tpica implica que (a) los
centros de datos tienen un gran nmero de archivos pequeos y (b) los archivos
en el extremo ms grande podran ser muy grandes en tamao y pueden estar
distribuidos en varios dispositivos o incluso grupos. Hacer un seguimiento de
un gran nmero de archivos implica desafos en la forma de representar de
manera eficaz, gestionar y manipular los metadatos de archivos. Sin embargo,
no podemos limitarnos a disear mecanismos que funcionan bien slo para
sistemas de archivos de gran tamao. El nmero de los objetos administrados

35
por diversas instancias del sistema de archivos tiene en s misma la
probabilidad de seguir distribuciones similares a Zipf. En consecuencia, la
gestin de meta-datos debe ser diseada para tomar ventaja de los pequeos
tamaos del sistema de archivos siempre que sea el caso. Problemas similares
aplican con respecto a tamao de los archivos tambin. El diseo debe ser capaz
de proporcionar asignacin, acceso y actualizaciones eficientes no slo para
archivos de gran tamao que pueden acumular petabytes, sino tambin a los
pequeos archivos que son slo unos pocos cientos de bytes.

Muchas aplicaciones emergentes implican trabajar con grandes cantidades de

datos, tanto de manera permanente como transitoria (o temporal). Una
compensacin adaptativa entre cmputo y almacenamiento puede ser til en el
trabajo con dichos datos. Por ejemplo, los datos que se acceden con poca
frecuencia podran ser comprimidos o ser regenerados cada vez mediante la
ejecucin de transformacin apropiada, simulacin o programa de filtrado. La
cuantificacin de la compensacin o compromiso (trade-off) entre computacin
y almacenamiento exige abordar cuestiones tales como (a) de almacenamiento
de energa vs CPU consumido, (b) impacto en el rendimiento de las tcnicas de
ahorro de almacenamiento, y (c) la colocacin de datos y la migracin a travs
de la jerarqua de almacenamiento.

Debido a sus muy diferentes caractersticas operativas, los dispositivos de

almacenamiento (discos duros, tecnologas de memoria principal, y SSD)
requieren nuevas estrategias de modelado. En particular, las actualizaciones de
datos deslocalizados, recoleccin de basura y nivelacin de desgaste perturban
las caractersticas de acceso del trfico entrante y deben ser abordados en el
modelado. Tambin, como un SSD obtiene cada vez ms desgaste con el
tiempo, sus operaciones de borrado se ralentizan considerablemente, lo que
requiere ms reintentos y mala reasignacin de bloques, reduciendo de este
modo el rendimiento efectivo del dispositivo. La GC y algoritmos de nivelacin
de desgaste tambin afectan el consumo de energa y tiempo de vida en formas
complejas que no son triviales para modelo.

Una cuestin relacionada con SSD, y ms generalmente con el

almacenamiento basado en NVRAM es volver a examinar la distincin
tradicional entre la memoria principal y acceso al almacenamiento secundario.
Cuando un hilo de hardware se detiene para el acceso al disco, el sistema
operativo toma el control y pasa el hilo a otro proceso de SO ya que la latencia

36
de finalizacin E/S es muy grande en comparacin con el coste de un cambio
de contexto. Sin embargo, tal cambio no tiene sentido para un acceso a la
memoria.

Contando con almacenamiento de estado slido muy rpido, tal distincin

podra dejar de presentarse y un mecanismo de cambio de contexto adaptativo
puede ser necesario. Adems, un almacenamiento de acceso rpido expone los
altos gastos indirectos de la capa del sistema de archivos tradicional, y es
necesario volver a examinar modelo de acceso a archivos tradicional para que
sea sustancialmente ms ligero. En este contexto, una pregunta relevante a
preguntarse es si la capa de almacenamiento intermedio debe realmente ser
accedida como almacenamiento secundario o simplemente como una memoria
de nivel superior, o tal vez como algo intermedio. En este contexto, varios
autores examinan el uso de un sistema de memoria de varios niveles utilizando
NVRAM para evaluar las ventajas de rendimiento.

Las tcnicas de virtualizacin de almacenamiento discutidas anteriormente

se dirigen principalmente hacia la agregacin de un gran nmero de
dispositivos de almacenamiento y la creacin de un nico subsistema de
almacenamiento desde el cual se puede asignar espacio a varias aplicaciones.
Tal punto de vista no es suficiente para el modelo de centro de datos virtual
(VDC). En particular, cada VDC puede requerir su propia particin de
almacenamiento con el aislamiento y la proteccin adecuados de otros CDA, y
sin embargo, debera ser posible desplazar los lmites de la particin segn sea
necesario. Adems, debera ser posible para gestionar el almacenamiento en
cada VCC a un nivel bastante bajo de modo, que cada CDA puede configurar el
almacenamiento en funcin de sus necesidades. Proporcionar tal capacidad de
"desagregacin", adems de la capacidad de adicin usual utilizada, es
actualmente un problema abierto que no est contemplado en las capacidades
de almacenamiento ofrecidas por las nubes actuales.

37
6 Gestin de la configuracin en los centros de datos

La gestin global de los activos del centro de datos tiene necesariamente que
lidiar con su ciclo de vida. El ciclo de vida se extiende desde el punto de que el
activo ingres en el centro de datos, hasta que finalmente se retir del servicio,
como se discute en ms detalle en el Captulo 6.1.

Gestin generalmente implica dos partes distintas: (a) las operaciones y (b) el
control. En trminos generales, las operaciones se refieren a la instalacin,
configuracin, actualizacin y otras actividades de tiempo con gruesa
granularidad; mientras que el control se refiere a la gestin de grano fino de los
recursos.

Tradicionalmente, la parte de control ha sido manejada por el lado de "in-

band" (es decir, por el sistema operativo y middleware), mientras que las
operaciones son manejadas por el lado de fuera de banda (OOB), que se ejecuta
en el controlador de gestin de placa base (BMC). Sin embargo, a medida que
avanzamos a la gestin del modelo ms general DVDC discutido
anteriormente, esta distincin entre las operaciones y el control o la separacin
entre el fuera de banda y las actividades dentro de banda se vuelve menos
clara. Por ejemplo, la configuracin o la reconfiguracin de una mquina
virtual podra ser considerada parte de las actividades de control. Del mismo
modo, la informacin obtenida de ambos OOB y en banda debe combinarse
para una configuracin y control efectivo.

La gestin de centros de datos modernos implica un gran nmero de

cuestiones que se hacen ms difciles a medida que el nmero de objetos
administrados aumenta. A continuacin se discuten estos temas y los
problemas de escalabilidad correspondientes.

6.1 Gestin del ciclo de vida

Puede ser tentador pensar en centros de datos y servicios de TI como algo
esttico, donde las instalaciones se instalan y luego se usan por un largo tiempo
antes de ser retirado. En realidad, la mayora de las instalaciones estn sujetas a
constante cambio : nuevos activos se instalan, y los existentes son actualizados,
reconfigurados, reutilizados, movidos a otra ubicacin geogrfica, o
reemplazados. Por consiguiente, es importante para automatizar estas tareas en
la medida de lo posible, de modo que las actividades de gestin se puedan

38
realizar de forma rentable (por ejemplo, con un mnimo de tiempo
administrador de TI), rpidamente, de forma segura, y con mnima exposicin a
errores humanos. A continuacin, se elabora sobre los desafos de la gestin del
ciclo de vida automatizado.

Considere una situacin en la que un nuevo servidor modular llega a una

instalacin y es conectado a alguna ranura vaca en un rack o un chasis. Con el
fin de aadir lgicamente este servidor a la instalacin, se requieren las
siguientes tareas:

1. Descubrimiento : Este paso implica el descubrimiento de la configuracin

HW / SW de cada dispositivo y el servidor en su conjunto para que pueda ser
desplegado correctamente. La informacin producida por el descubrimiento
necesita ser almacenada en una forma estndar, de modo que se pueda utilizar
para los pasos de cualificacin y aprovisionamiento que se discuten a
continuacin.

2. Cualificacin : Un nuevo servidor bien podra acoger HW / SW malicioso

y no debera permitirse el ingreso al centro de datos sin un procedimiento que
permita verificarlo. Este paso pone en cuarentena inicialmente el servidor al
habilitar opciones de filtrado en el switch y/o router de conexin, de modo que
no sea capaz de enviar paquetes a destinos restringidos. El control para ello
implica al menos 3 aspectos: (a) autenticacin (tal vez basada en un certificado
almacenado en la memoria a prueba de manipulaciones [TPM] del servidor), (b)
revisin constante para la deteccin de malware, y (c) el cumplimiento de los
controles que aseguren que se ajusta a las polticas de TI que desee.

3. Aprovisionamiento : Este paso prepara el servidor para la instalacin e

incluye una variedad de tareas, tales como particionamiento, configuracin de
HW, puesta a punto, y la carga de programas del sistema base. Es probable que
el particionamiento y configuracin dependa de los parches de servidor a los
cuales el nuevo activo ser aadido.

4. Prestacin de Servicios : Este paso asignar las particiones del servidor (o

incluso las mquinas virtuales que se ejecutan en ellas) a los centros de datos
virtuales adecuados, y las aprovisionar con el software de aplicacin necesario,
acceso a la red/almacenamiento, etc.; para que puedan comenzar a prestar los
servicios previstos.

5. Supervisin y ajuste : Se refiere a la vigilancia constante de los parmetros

39
vitales del servidor y la adopcin de medidas adecuadas. Los datos de
vigilancia de diversos elementos HW y SW se implican tpicamente el filtrado,
el almacenamiento y la fusin con el fin de detectar y resolver problemas de
rendimiento, minimizar el consumo de energa, determinar los ataques de
seguridad, etc.

6. Correccin : Se refiere a las actividades relacionadas con la deteccin y

diagnstico de fallos, la seguridad relacionada con la cuarentena, reparacin,
actualizacin y reemplazo. Algn tipo de correcin puede ser necesaria
mientras que el servidor est en uso y por lo tanto puede interferir con el
servicio.

Los tres primeros pasos en esta lista incluyen BMC, que es la nica parte del
servidor que aparecer automticamente cuando un nuevo servidor se conecta.
El aprovisionamiento se inicia con el BMC encendiendo el servidor principal y
comunicndose con su firmware para arrancar el proceso de descubrimiento y
cualificacin. Muchas de las otras tareas se pueden hacer en o fuera de banda, o
mediante una combinacin de ambas.

6.2 Marcos operacionales de gestin

Hay dos requisitos fundamentales que permiten la deteccin y configuracin
automtica : (a) La disponibilidad de la informacin de configuracin en un
formato estandarizado en cada dispositivo y en los niveles superiores, y (b) un
marco estandarizado para recuperar y procesar esta informacin. El modelo de
informacin comn (CIM) fue desarrollado por el grupo de trabajo de
administracin distribuida (DMTF) para describir entidades informticas y de
negocios, y ha sido adoptado ampliamente. CIM es un lenguaje jerrquico y
orientado a objetos de informacin de gestin basado en UML (Unified
Modeling Language) para la definicin de los objetos y las interdependencias
entre ellos. Aparte de las relaciones estructurales, CIM puede expresar una
variedad de dependencias tales como las que existen entre las conexiones de
red y adaptadores de red subyacentes, SW y HW en el que se ejecuta, etc.

Un esquema CIM define un objeto en el estilo de entidad-relacin y permite

conceptos de modelado orientados a objetos tales como clases anidadas, de
instancias, herencia, y agregacin para permitir una descripcin compacta de
los sistemas complejos en trminos de sus componentes. Por ejemplo, se espera
que un modelo de CIM de un NIC de Ethernet pueda proporcionar no slo la
estructura fsica de la tarjeta NIC, sino tambin los parmetros/capacidades
40
que se necesitan para el uso y la configuracin de la tarjeta de red, velocidades
PHY disponibles o capacidad de comprobacin CRC en HW. El modelo CIM
tambin proporciona su configuracin (por ejemplo, la velocidad PHY actual y
si HW CRC est activada) y los mtodos para cambiar los valores.

DMTF ha desarrollado la especificacin de gestin empresarial basada en

Web (WBEM) que proporciona mecanismos para el intercambio de informacin
CIM de manera interoperable y eficiente. Los componentes de WBEM incluyen
la representacin de la informacin CIM utilizando XML, las operaciones de la
CIM a travs de HTTP, la gestin de los servicios web basados en WSMAN, el
lenguaje de consulta CIM, interfaz de lenguaje de comandos (CLI), y el
protocolo de ubicacin de servicios CIM. Una popular implementacin de
cdigo abierto de WBEM es un llamado CIMOM (Administrador de objetos
CIM). WSMAN define un conjunto de operaciones por medio de SOAP (Simple
Object Access Protocol) que se puede utilizar para consultar y actualizar los
repositorios de la CIM. SOAP se ejecuta en la parte superior de HTTP y debido
a su carcter de texto sin formato, las operaciones basadas en SOAP son fciles
de depurar, pero puede ser muy pesado en trminos de sobrecarga (overhead).

Los modelos CIM representan sistemas y sus parmetros sobre todo a nivel
estructural (la mayor parte de la semntica de los parmetros y la inteligencia
para configurar adecuadamente se encuentra fuera del mbito de la CIM). Por
ejemplo, la CIM no est diseada para especificar las relaciones complejas entre
los valores de los parmetros de varias entidades o las condiciones en que los
parmetros deben establecerse de una manera particular. Tradicionalmente,
esta inteligencia se encuentra en el cdigo de gestin. El consorcio World Wide
Web (W3C) ha estandarizado recientemente el lenguaje de modelado de
servicios (SML) para llenar este vaco. SML puede describir esquemas
utilizando XML DTD 's (definiciones de tipos de datos). Los documentos SML
pueden hacer referencia a elementos en otros documentos SML y pueden
especificar relaciones complejas con Schematron. As, SML puede permitir la
gestin de los recursos basada en las limitaciones declaradas. Sin embargo, la
especificacin y el procesamiento de las restricciones complejas utilizando un
lenguaje declarativo como SML sigue siendo todo un reto.

6.3 Almacenamiento de datos de gestin

El repositorio de CIM de un activo de centro de datos puede ser considerado
como una base de datos de configuracin local que se puede consultar y

41
actualizar mediante WSMAN, CIM-CLI u otros medios. Sin embargo, depender
exclusivamente del repositorio de la CIM para hacer aprovisionamiento u otras
decisiones se vuelve poco prctico, incluso con un pequeo nmero de
servidores, por dos razones: (a) repositorios CIM suelen almacenar valores de
los parmetros detallados de dispositivos individuales en lugar de atributos de
nivel superior (por ejemplo, la capacidad del servidor) que se requieren para la
administracin dinmica y (b) el acceso a repositorios de CIM es generalmente
muy lento debido a su base de firmware y la interfaz de servicios web. Una
gestin viable requiere invariablemente alguna base de datos de nivel superior
que contenga no slo porciones de la CIM del repositorio, sino tambin algunos
atributos derivados que se pueden utilizar ms directamente en la toma de
decisiones de aprovisionamiento. Esta base de datos se conoce a menudo como
la base de datos de gestin de configuracin (CMDB). De hecho, una CMDB no
depende enteramente de repositorios CIM, sino que tambin puede contener
una cantidad significativa de datos operativos obtenidos tanto desde fuera de
banda y las interfaces en banda.

Figura 15. Componentes de CIM (Common Information Model)

En la prctica, los proveedores de software de gestin ofrecen una variedad

de productos dirigidos hacia la gestin de aspectos especficos. Por ejemplo,
una serie de paquetes estn disponibles para el aprovisionamiento de equipos,
la supervisin del rendimiento, gestin de aplicaciones, migracin, etc. En
adelante los llamamos paquetes de gestin externos (EMP). Muchos EMP
utilizan repositorios de datos privados por conveniencia, que pueden no ser

42
compatibles con los dems. Los datos de algunos de los planes de gestin (por
lo general los del mismo proveedor) pueden consolidarse en una sola CMDB,
pero esto an deja el problema de administrar varias CMDB. El resultado es
una serie de repositorios con superposicin o solapamiento de informacin,
pero incompatibles entre s. El enfoque alternativo de un nico sistema de
gestin integral de un solo proveedor tambin es indeseable debido a la falta de
flexibilidad.

En el pasado, las bases de datos de configuracin (CIM-DB, paquete de DB o

CMDB) tuvieron tendencia a ser ms bien estticaa. De hecho las bases de datos
CIM-DB, al estar basadas en firmware y ser difcil de modificar, an contienen
principalmente informacin que puede ser modificada de vez en cuando a
travs de la BIOS, EFI (Interfaz de firmware prolongado) u otro programa de
control de pre-arranque. Un ejemplo de una funcin utilizada con poca
frecuencia es la activacin /y desactivacin del HW threading. Por otro lado,
una gestin gil requiere el acceso a una gran cantidad de informacin
dinmica, tal como consumo de corriente de alimentacin o la utilizacin del
ancho de banda disponible. En un entorno virtualizado, incluso los parmetros
de configuracin, como la cantidad de memoria instalada y el ancho de banda
de NIC virtuales se convierten dinmicamente en parmetros modificables. Este
dinamismo trae una serie de problemas y las soluciones son cada vez ms
difciles de escalar a grandes centros de datos.

Mantener la informacin del nivel de activos (por ejemplo, la velocidad

actual de la NIC) en un repositorio local (como el CIM-DB u otro repositorio
basado en disco o SSD) es atractiva, ya que permite una gestin limpia,
descentralizada y fcilmente paralelizable. En el entorno virtualizado, los
parmetros de todas las mquinas virtuales que se ejecutan en la mquina fsica
tambin se mantienen mejor a nivel local. Sin embargo, las decisiones acerca de
dnde una nueva mquina virtual debe asignarse requeriran al menos parte de
la informacin disponible en un nivel superior.

La duplicacin de datos a travs de mltiples repositorios inmediatamente

trae a cuestin el mantenimiento de la consistencia y fuerza a una consideracin
cuidadosa de cual informacin debe mantenerse, dnde y en qu forma. En un
extremo, slo los datos estticos (o rara vez cambiados) se conservan en el nivel
ms alto y todos los datos dinmicos se obtienen de repositorio de activos,
segn sea necesario. Este enfoque se convierte rpidamente en poco escalable a

43
medida que aumenta la dinmica de datos, en particular con respecto a la
informacin residente en el firmware. En el otro extremo, el mantenimiento de
datos dinmicos principalmente en bases de datos externas no slo es imposible
de escalar sino que tambin introduce dependencias indeseables. Por ejemplo,
la imposibilidad de acceder a la base de datos externa podra daar la
configuracin de activos y causar accidentes.

Claramente, se desea un enfoque intermedio, pero no existe un marco terico

para guiar qu informacin debe ir a dnde. La idea general sera la de
almacenar la informacin directamente ms til, pero a la vez ms abstracta en
los niveles superiores; sin embargo, es muy difcil la formalizacin de dicha
nocin. Como un ejemplo, la CMDB puede almacenar la capacidad de
computacin de servidor, el cual, a su vez, depende de los parmetros de nivel
inferior, tales como el nmero de ncleos habilitados o la velocidad de la
memoria. En este caso, si se realiza una actualizacin de los parmetros de los
activos, tenemos que determinar si afecta a los datos de CMDB y si es as, los
datos derivados de CMDB deben ser actualizados. La dificultad obvia es que si
la relacin entre los datos extrados y los datos de nivel inferior no es explcita
(por ejemplo, oculta en el cdigo), se presenta un problema tanto con la
consistencia (falso negativo) y la actualizacin innecesaria (falso positivo) en las
actualizaciones.

Para habilitar la gestin integrada de un sistema complejo, a menudo es

necesario interrelacionar la informacin de mltiples bases de datos. Por
ejemplo, un paquete de aprovisionamiento puede mantener la informacin
detallada de uso de recursos, pero slo un resumen de la informacin relativa a
los fallos. En contraste, un paquete que administre el reemplazo de los activos
o su actualizacin puede hacer justo lo contrario. Combinar la informacin de
estas dos bases de datos puede ser muy difcil debido a las diferencias en el
nivel de detalle y la semntica precisa de datos. Por otra parte, el filtrado y la
abstraccin empleada en los datos entrantes antes de proceder a su guardado
puede ser oculto en el cdigo, en lugar de especificarse claramente o
formalmente.

Hay dos enfoques para la coordinacin de mltiples CMDBs y ambas

implican una entidad de nivel superior, que debe tener interfaces para cada
CMDB existente o bases de datos EMP con las que interacta. Una posibilidad
es dejar que el ms alto nivel de la propia entidad sea una CMDB que mantiene

44
una versin coherente de todos los datos pertinentes abstrados de bases de
datos de nivel inferior. Este es un reto no slo en trminos de crear una visin
unificada de los datos, pero tambin puede ser infranqueable debido a la
centralizacin de todos los datos en una CMDB.

Un mtodo alternativo es hacer de la entidad de nivel superior un directorio

de referencia global (GRD), similar al directorio de recursos empresariales
escalables (SERD) basado en la arquitectura definida por Dell e implementado
por Altiris. La principal diferencia entre la CMDB de nivel de GRD y la parte
superior es que los GRD almacenan principalmente "lazos" a los datos ubicados
en otras bases de datos, y algunos de los atributos derivados o datos de ms
alto nivel que pueden ser ms directamente tiles en la toma de decisiones. Los
mtodos para relacionar objetos derivados de los parmetros objeto de base son
necesariamente una parte de esta descripcin. GRD tambin mantiene otras dos
cosas : (a) Las polticas para decidir qu EMP invocar y los parmetros que se
pasan a la misma, y (b) los Triggers que definen la funcionalidad de gestin
que se activar bien sea a travs de alertas del EMP o debido a los cruces de
umbral de los datos monitoreados directamente en CIM-DB. GRD puede ser
implementado usando las implementaciones de LDAP (protocolo ligero de
acceso a datos). Estas implementaciones son altamente escalables para datos de
slo lectura, pero no estn diseados para manejar datos altamente dinmicos.

En el contexto de nuestra Capa 4 del modelo DVDC discutido en el Captulo

3, se requiere la administracin de configuracin en las cuatro capas. Por
ejemplo, el PIL debe administrar una granja de servidores completa y dar
apoyo a la creacin de parches de servidores. El VIL debe ser capaz de utilizar
estas capacidades para crear y gestionar centros de datos virtuales. El VICL
utiliza entonces las capacidades VIL en varios lugares con el fin de apoyar el
concepto DVDC. Finalmente, el SPL necesita gestionar las aplicaciones y su
despliegue y debe tener suficiente visibilidad de las capas inferiores para hacer
aprovisionamiento adecuado y decisiones re-aprovisionamiento. Proporcionar
la visibilidad adecuada, la abstraccin y la proteccin a travs de esta jerarqua,
y hacerlo de una forma escalable plantea retos importantes de administracin.

6.4 Desafos en la Provisin de Servicios

En un gran ambiente virtualizado heterogneo, el aprovisionamiento de una
aplicacin o un servicio puede ser un problema complejo. En general, un nuevo
servicio tiene que usar varios servidores, y la identificacin de los servidores

45
apropiados requiere de por lo menos tres aspectos: (a) la capacidad residual del
servidor, (b) ancho de banda de red y almacenamiento disponible, y (c) las
latencias de acceso a los datos con los que la aplicacin trabajar. Para
aplicaciones en clster, existe tambin un cuarto elemento que se relaciona con
el ancho de banda de la comunicacin entre servidores y la latencia de sta.

Hay por lo menos tres problemas a resolver en el cumplimiento de estas

tareas: (a) la traduccin de las caractersticas de carga de trabajo de aplicacin
en las capacidades requeridas, (b) estimacin de la capacidad disponible de
servidores y la red, y (c) diseo de algoritmos para mapas de aplicaciones /
servicios en base a las capacidades y funciones disponibles. Cada uno de ellos
es un tema complejo y se vuelve an ms para los DVDC ejecutando una
amplia variedad de cargas de trabajo. Por otra parte, la nocin de capacidades
"disponibles" y "necesarias" aade una importante complejidad. En general, las
cargas de trabajo pueden interferir unas con otras, y la propiedad de aditividad
de disponibilidad y necesidad de capacidad es a menudo insostenible. La
nocin de ancho de banda equivalente se utiliza con frecuencia en el contexto
de la creacin de redes para permitir la aditividad : Se necesita una idea similar
para capacidades computacionales y de almacenamiento.

Para ciertos entornos y aplicaciones, las capacidades disponibles y necesarias

pueden fluctuar significativamente, una primera estimacin precisa puede
incluso no ser muy valiosa. Una forma extrema es la seleccin de los servidores
basados en un mnimo de informacin sobre la utilizacin de los diversos
recursos y caractersticas de carga de trabajo brutos conocidos (por ejemplo,
CPU requerido versus IO requerido).

En este caso, el problema de la asignacin de capacidad adecuada se maneja

a travs de rendimiento impulsado por el cambio del tamao de una VM
dinmica o la migracin de sta. Una estimacin ms precisa de la capacidad
disponible se puede hacer mediante el BMC o controlador de nivel ms alto y
las capacidades requeridas a travs del modelado de la carga de trabajo.
Obviamente, hay un equilibrio entre la precisin de la estimacin, la estabilidad
de carga de trabajo y la frecuencia de la migracin, pero esto no es fcil de
caracterizar. Tcnicas de aprendizaje de la mquina, pueden ser tiles en este
sentido.

El reaprovisionamiento dinmico de un servicio o una aplicacin pueden ser

provocados por una de tres consideraciones: (a) sobredemanda de recursos en

46
uno o ms nodos (incluido el ancho de banda de comunicacin), (b) las
consideraciones de optimizacin (por ejemplo, mover la aplicacin hacia un
servidor con poca carga de manera que se obtengan mejores estados de bajo
consumo), o (c) ocurrencia de eventos especficos, como fallas o actividades de
mantenimiento. De ellos, (a) y (b) requieren del equilibrio de varios factores
incluyendo el coste de no hacer el cambio, el coste de control, coste de
reaprovisionamiento, y el coste de seleccionar una opcin incorrecta de
servidores a los que se mueve la carga de trabajo. En la mayora de los casos, es
difcil hacer que estas soluciones sea eficientes, debido a la complejidad del
entorno. Algunos autores discuten el uso de tcnicas de aprendizaje automtico,
por ejemplo, para la gestin coordinada de mltiples recursos en
multiprocesadores. Tcnicas similares pueden ser tiles en contextos provisin
dinmica ms genera. En el caso de (c), el aspecto ms importante es reanudar
rpidamente el servicio en vez de hacer la eleccin ptima de un nuevo
servidor. Por ejemplo, el servicio puede ser trasladado primero a otro servidor
en el mismo chasis / bastidor para reducir al mnimo la latencia de la migracin
de la VM.

6.5 Desafos en la Gestin de Procesos

La discusin en el Captulo 6.3 se centr en la jerarqua de gestin de base de
datos y los problemas causados por mltiples bases de datos. Esta discusin
asume implcitamente que los paquetes de gestin externos (EMP) pueden
manejar de forma transparente todos los activos del centro de datos. Los
propios datos de activos podran estar contenidos en una base de datos nica o
dividirse solamente los niveles ms altos (por ejemplo, base de datos por
emplazamiento fsico). Sin embargo, la funcionalidad de administracin en s
requiere una estructura ms descentralizada. Por ejemplo, la arquitectura del
centro de datos obliga a una jerarqua de gestin de la participacin a nivel de
servidor, chasis / rack y nivel de parches del servidor. De hecho, una gestin
integral implica mltiples dominios y una jerarqua dentro de cada dominio. En
un centro de datos virtualizado, hay por lo menos cuatro dominios distintos de
inters, cada uno con una jerarqua de gestin. A continuacin se describen
brevemente estos dominios y sus potenciales niveles :

1. Los activos fsicos: Se refiere a las agrupaciones fsicas de activos y

diversos atributos de cada grupo fsico (por ejemplo, las jerarquas del consumo
de corriente y la potencia mxima permitida, el nmero de servidores

47
infrautilizados, etc.). El nivel superior de esta jerarqua es relevante slo si el
centro de datos se extiende a travs de mltiples ubicaciones fsicas.

2. Activos virtuales: Se refiere a mquinas virtuales y sus agrupaciones en

trminos de jerarquas por clster de aplicaciones, el centro de datos virtual
(que se define en un conjunto de servidores), y todo el DVDC. Se requiere esta
jerarqua para aprovisionar recursos para aplicaciones y centros de datos
virtuales.

3. Infraestructura de red: La gestin de la infraestructura de red trata del

plano de gestin de switches y routers. Esta jerarqua refleja la estructura de la
red fsica. La gestin de la red a travs de servidores fsicos se encuentra en el
dominio del ISP y por lo tanto no est incluido.

4. Infraestructura de software: Tiene que ver con el seguimiento de los

componentes de software y sus dependencias.

El propsito principal de la estructura jerrquica es simplificar la gestin. La

jerarqua requiere dos funciones importantes: (a) la descomposicin de una
solicitud de nivel superior en sub-peticiones que pueden delegarse a los niveles
ms bajos, y (b) la propagacin de los resultados y las excepciones al mayor
nivel consolidado. Por ejemplo, en el aprovisionamiento de una aplicacin que
requiere muchos servidores, podemos elegir el conjunto de bastidores que sern
sede de la aplicacin, y dejar la tarea de elegir los servidores reales en el
bastidor al gestor de bastidores. Esto permitira algoritmos que se utilizaran
dentro de un rack, siendo el nico componente a normalizar la interfaz entre los
niveles. Si el nivel de bastidores es incapaz de manejar la tarea asignada, se
producir una excepcin en el nivel superior. Tal mecanismo se proporciona
para toda una serie continua de polticas de interaccin entre nivel: en un
extremo, el nivel ms alto puede seleccionar las siguientes entidades de nivel
casi al azar y depender del mecanismo de excepcin de correctitud, y por el
otro la delegacin se gestiona cuidadosamente a modo que esta excepcin se
produzca raramente.

Mientras que los retos de la negociacin, la delegacin y retroalimentacin

surgen de cualquier jerarqua, estos se hacen an ms complejos por la
presencia de mltiples bases de datos incompatibles. Adems, muchas
actividades requieren la cooperacin entre los distintos mbitos : por ejemplo, la
provisin de una aplicacin en clster requiere el establecimiento de un nuevo

48
grupo de mquinas virtuales, sin embargo, la asignacin de este grupo a la
infraestructura fsica requiere de la interaccin entre los dominios virtuales y
fsicos. En otras palabras, los controladores de las cuatro jerarquas no operan
en forma independiente, sino que necesitan comunicarse y coordinarse con el
fin de realizar las diferentes tareas del ciclo de vida, indicadas en el Captulo
6.1. Por lo tanto el diseo de una arquitectura global de cooperacin entre
jerarquas de controladores es en s una tarea difcil.

La cuestin del control en banda y fuera de banda tambin es importante en

el diseo de una arquitectura completa. Como se dijo anteriormente, el nivel de
procesador fuera de banda del servidor (o BMC) supervisa y controla ciertos
aspectos como el estado del servidor, velocidades de ventiladores o el consumo
de energa; mientras que el controlador dentro de la banda est ms ocupado
por los problemas de rendimiento. En general, es posible que las
funcionalidades en banda y fuera de banda tengan sus propias jerarquas, cada
una suministrada por un proveedor diferente. La coordinacin entre las dos
partes en ste caso es compleja, pero esencial para una gestin eficaz.

Debido a su naturaleza modular, los activos del centro de datos se pueden

mover fcilmente, y por lo general lo hacen por una variedad de razones. En un
centro de datos grande, es difcil hacer un seguimiento de estos activos. As, la
gestin de activos se ha convertido en un problema importante en los centros
de datos y soluciones para la localizacin de los servidores en un centro de
datos se utilizan con frecuencia. El estndar USB inalmbrico emergente puede
ser explotado para la localizacin y referencia precisa de activos y se basa en l
para proporcionar servicios basados en la ubicacin en el centro de datos.

49
7 Requisitos de la Gestin de Recursos en Centros de Datos

En ste Captulo trataremos los requerimientos del software para la Gestin

y Administracin de recursos en Centros de Datos, considerando los aspectos
relacionados con la Monitorizacin, Anlisis de Datos, Toma de Decisiones y
Automatizacin de Tareas. Posteriormente, discutiremos la evolucin de las
herramientas de arquitectura abierta para la gestin de CPD.

Es comn hoy en da administrar el uso compartido de la red a travs de

middleware o software de gestin de los recursos disponibles. La eleccin
arquitectnica de virtualizar a nivel de infraestructura es una totalmente nueva
direccin que es complementaria a la amplia gama de enfoques de middleware
existentes. La propuesta de valor que se ofrece es un intercambio seguro y
eficaz en un menor nivel de abstraccin.

Por ejemplo, un usuario puede obtener una instancia de mquina privada a

pedido en vez de al servicio que encola su trabajo a la espera de que se ejecute
en otro equipo. En este ejemplo, la abstraccin de mquina ofrece a los usuarios
acceso a la carta y el control sobre entornos computacionales personalizados.
Los sistemas de computacin virtuales tambin pueden ofrecer garantas de
comportamiento predecible y el aislamiento de otros usuarios, utilizando
tecnologas de virtualizacin para controlar la unin de los entornos de los
huspedes a los recursos fsicos de alojamiento.

Esta funcionalidad depende de una nueva capa fundacional de software de

control que crea una instancia y manipula los contextos en los que las
aplicaciones, middleware y sistemas operativos se encuentran. Puesto que
controla la parte inferior de la pila de software ms cercana a la de hardware,
nos referimos a esta capa de control como underware para distinguirla de
middleware clsica. Una caracterstica clave del underware es que no es
visible para los usuarios o las aplicaciones en la parte superior de la pila de
software, excepto para proporcionar un entorno ms estable y controlado para
que se ejecuten. Su papel es el de proteger y mejorar las inversiones en
software de alto nivel (incluyendo middleware), simplificando la
infraestructura de gestin, y facilitar el acceso.

A medida que los centros de datos crecen en tamao y proliferan, hemos

visto una amplia gama de aplicaciones que evolucionan para tomar ventaja de

50
este entorno. Servidores Web con mltiples niveles, aplicaciones de renderizado
multimedia, simulaciones a gran escala, y otras cargas de trabajo orientadas a
servicios son ya escalables a un gran nmero de servidores. Este nuevo mundo
plantea retos tanto a los propietarios de estos centros de datos y los clientes o
usuarios que ejecutan las aplicaciones. Los propietarios de centros de datos
deben gestionar los recursos a nivel de instalaciones, como la red elctrica los
aires acondicionados de las salas de ordenadores, adems de tecnologa de TI
tradicional. Los usuarios deben gestionar las aplicaciones que se pueden
ejecutar en el hardware compartido, incluidas las mquinas virtuales y las redes
de rea local virtuales y en entornos heterogneos. La magnitud de este desafo
ha motivado el trabajo reciente en marcos de supervisin y control coordinada
de las infraestructuras de computacin a gran escala. Los enfoques ms
comunes se basan en controlar, analizar, planear y ejecutar lazos de control.

Una infraestructura de instrumentacin registra lecturas de los sensores, que

se someten a anlisis de datos. Los resultados del anlisis se alimentan a un
motor de polticas, que crea un plan de cmo utilizar los recursos. Por ltimo,
las interfaces externas a los objetos de centros de datos permiten al
administrador u otros actores controlar el centro de datos y reaccionar a las
condiciones cambiantes desde ubicaciones remotas de una manera rpida. Por
ejemplo, los ambientes comerciales tales como OpenView y Tivoli informacin
agregada presentan una supervisin grfica y una interfaz de control a los
administradores a partir de una variedad de fuentes de informacin.

La investigacin reciente se centra en extender el estado de la tcnica a tres

aspectos importantes. El primero, hacia los sistemas a escala de Internet, a
menudo usando una metfora sensores para la instrumentacin, el
aprovechamiento de la investigacin en redes de sensores de gran escala y las
consultas en sensores de infraestructuras rea amplia como PlanetLab.

Figura 16. Gestin de Infraestructura : Capa de Control (Underware)

51
 El segundo es el desarrollo de herramientas de anlisis para reconocer
patrones y diagnosticar anomalas en los datos. Por ltimo, dado que los
operadores humanos pueden ser incapaces de evaluar los eventos lo
suficientemente rpido como para responder con eficacia, hay un creciente
inters en "cerrar el crculo" con herramientas para planificar las respuestas, y
ejecutar la gestin del sistema a travs de interfaces de programacin
(actuadores). Este es un objetivo clave a largo plazo de las iniciativas de
computacin autonmica y las empresas de adaptacin respectivamente. Estas
tendencias se combinan en la idea de un "plano de conocimiento" para otros
sistemas de gran escala e Internet.

La informacin fsica tiene un papel importante que desempear en la

supervisin y control dinmico para la automatizacin del centro de datos y,
sobre todo cuando se combina con las mtricas de rendimiento. Como un
ejemplo motivador, consideremos la necesidad de administrar la energa y la
refrigeracin en un centro de datos. El costo de la energa para alimentar y
enfriar el equipo de un gran centro de datos es significativa. Por otra parte,
tendencias de la tecnologa estn impulsando el aumento de densidad de
potencia, en parte, para reducir los costes de espacio y cableado. Como
resultado, la infraestructura para la alimentacin y la refrigeracin es crtica
para la fiabilidad del servicio.

El consumo de recursos y la refrigeracin son esenciales. La instrumentacin

combinada es un requisito previo del control inteligente para ajustar la
infraestructura de refrigeracin controlada por software, a modo de equilibrar
la carga trmica y mejorar la eficiencia energtica, o predecir fenmenos
trmicos y responder mediante la migracin de cargas de trabajo o de
almacenamiento.

Un desafo fundamental que enfrentan estos proyectos, sin embargo, es cmo

llevar a cabo experimentos cientficos eficaces que permitan conocer estos
nuevos entornos. Hay una escasez de mtodos e instrumentos para obtener
datos y comprender las interacciones entre objetos en el centro de datos, desde
los componentes de bajo nivel para el desempeo de las aplicaciones de alto
nivel, para luego validar o rechazar hiptesis sobre cmo estos componentes
responden a cambios y optimizaciones futuras. Si vamos a aplicar el mtodo
cientfico a la gestin de centros de datos, debemos contar con las herramientas
adecuadas para llevar a cabo experimentos repetibles y verificables, y medir los

52
resultados.

7.1 Monitorizacin
Los Centros de Datos se han convertido en el corazn de las actividades de
negocio de las organizaciones. Sus complejas infraestructuras, en las que
convergen lo fsico y lo virtual, ha hecho que sus administradores tengan que
hacer frente a numerosos retos que tienen como fin ltimo optimizar los
recursos para dar una mejor respuesta a las necesidades del negocio, de los
clientes y de los empleados.

Los responsables deben definir los parmetros necesarios para que estos
Centro de Datos ofrezcan servicios de calidad y sean capaces de estar
preparados para futuros requerimientos, adaptndose a las nuevas tecnologas
y reglamentos, al tiempo que se mantiene estable el control de costos, se mejora
la productividad, se reduce el consumo energtico y se consigue un mejor
aprovechamiento de los recursos.

Es por esto, que se hace necesario e imprescindible prestar una especial

atencin a todas las infraestructuras del Centro de Datos y proceder a su
monitorizacin, tanto interna como externa.

Un Centro de Datos bien administrado est preparado para responder ante

las eventualidades, permite una rpida posicin ante la toma de decisiones y no
compromete la disponibilidad. Las instalaciones que implementen soluciones
de monitorizacin sern las que presenten unas instalaciones ms adaptables,
econmicamente sostenibles y ecolgicamente eficientes.

Las herramientas de DCIM (Data Center Infrastructure Management)

proporcionan una completa informacin para gestionar los recursos crticos de
un Data Center, permitiendo que sus responsables puedan definir objetivos de
rendimiento que respalden las operaciones globales de la organizacin.

Figura 17. Integrated Data Center Infrastructure Management

53
 Con las soluciones de DCIM se localizan, visualizan, identifican y
administran los recursos fsicos del Data Center (servidores, rack, sistemas de
almacenamiento, de energa y refrigeracin...), as como virtuales; al tiempo que
se obtiene informacin para medir, monitorizar, gestionar y controlar el
rendimiento del consumo de energa de las estructuras.

De esta forma, es posible mejorar la productividad, reducir los costes y

optimizar la capacidad de planificacin para un futuro crecimiento, ya que se
consigue un control ms eficaz de todos los activos.

Una solucin de DCIM debe ofrecer una visin holstica, que permita la
mejora continua de la infraestructura crtica, que aporte una visin global y en
tiempo real de toda la instalacin, tanto de la infraestructura informtica
(virtual, fsica y las cargas de trabajo a nivel de software) como del entorno de
instalacin (alimentacin elctrica, enfriamiento, etc.). De esta forma, se podr
conocer la localizacin, capacidad y disponibilidad de todos los recursos y estar
preparado para dar respuesta a posibles eventualidades, preparar cambios o
modificaciones.

El pilar de las soluciones de DCIM se sustenta sobre una base de datos que
sirve de repositorio de todos los recursos, atributos y relaciones del Data
Center, adems de los aplicativos necesarios para buscar, documentar y
visualizar los sistemas fsicos y virtuales. La automatizacin es otra de las claves
de estas soluciones y, por eso, la mayora de estos productos incluyen
funcionalidades automticas que facilitan la creacin y gestin de la base de
datos y otras prestaciones que agilizan los procesos.

El Sistema de monitorizacin de seales y alarmas de las infraestructuras nos

muestra y gestiona la informacin en tiempo real del estado de las diferentes
infraestructuras y equipamientos del CPD. Los datos se recopilan mediante
sondas o sensores y una unidad de proceso se muestra al usuario de diversas
formas.

Figura 18. Gestin de IT y Servicios de Negocio (DCIM)

54
 La informacin recopilada debe ser transmitida de forma inmediata para que
los interesados puedan intervenir. Las maneras ms habituales son mediante IP
Webserver, envo de e-mail, envo de SMS, envo de traps y centralizacin en
gestores de edificios, etc.

Algunas de las alarmas deben ser capaces de interactuar con otros equipos
para la minimizacin de daos como puede ser el apagado automtico de
servidores (Shut Down), actuacin de contactores y relees y actuacin en electro
vlvulas.

Caractersticas como el registro de logs deben estar consideradas para tener

un control sobre los eventos ocurridos.

Los principales beneficios de este sistema de monitorizacin centralizada

para el cliente son:

Informacin de forma continua y en tiempo real del estado de los

sistemas del CPD

Control de los eventos en un registro

Mayor disponibilidad de los sistemas al estar monitorizados de manera

continua

Anticipacin ante posibles incidencias

Disminucin del tiempo de respuesta en caso de incidente mediante el

envo instantneo de alarmas y avisos

7.2 Anlisis de Informacin en Tiempo Real

A medida que los sistemas de TI de la empresa responden a los cambios de
los ltimos aos, se hace cada vez ms importante repercutir estos cambios en
los mtodos y herramientas destinados a la instrumentacin de sistemas,
anlisis, respuesta y emulacin. En particular, atendiendo dos necesidades
fundamentales : la necesidad de mtodos de vigilancia que aborden de manera
integral la instrumentacin del sistema desde los dominios de TI y hasta los
emplazamientos en donde estos se encuentran; y la necesidad de una emulacin
ms detallada y flexible de los actuales ambientes consolidados de multi-
usuarios y multi-aplicaciones.

Para hacer frente a la primera necesidad, es comnmente utilizada la nocin

55
de planos conocimiento, ampliados para incluir informacin de ubicacin
espacial e informacin de los sensores ambientales. Las arquitecturas
propuestas incluyen comunicacin de datos y motor de filtrado, as como un
esquema de base de datos implementada en la parte superior de una base de
datos relacional, diseada para fcil extensibilidad, escalabilidad y apoyo a la
visibilidad de objetos de alto nivel y eventos en el centro de datos.

Para hacer frente a la segunda necesidad, se desarrollan anlisis de datos ms

amplios en un marco de reproduccin. Las capturas de anlisis de datos
atribuyen tendencias de comportamiento y propiedades de correlacin entre los
atributos a travs del uso de tcnicas matemticas (modelos ocultos de Markov,
EM clustering, etc.) que permiten capturar y condensar importantes
propiedades de los registros estadsticos de comportamiento del sistema. Estas
herramientas de reproduccin de datos buscan recrear las condiciones de uso
de recursos de inters especfic. Como ejemplo de este tipo de herramientas, se
encuentra la aplicacin SeASR.

7.3 Evolucin de las Arquitecturas abiertas en la Gestin de Recursos

La combinacin de recursos disponibles en los centros de datos actuales
ofrecen beneficios tangibles y convincentes. A pesar de ello, la tecnologa para
su eficaz gestin est en una etapa temprana. La computacin virtual es un
nuevo segmento de mercado, as como una zona rica para la investigacin.
Ofrece una rara oportunidad para repensar la arquitectura de software y
aprovechar las nuevas capacidades de una manera que se aplica a los beneficios
en trminos generales a una amplia gama de entornos de computacin,
incluyendo los sistemas existentes de middleware, computacin en malla y en
clster, los servicios Web y sistemas an por crearse.

Todo ello motiva a un mayor nfasis en las implicaciones de las polticas de

control de recursos como mecanismos esenciales, pero alguien o algo debe
controlar la forma en que se utilizan. Estas funcionalidades crean un espacio
rico para las infraestructuras de gestin de sistemas. Es sencillo exponer estas
opciones a operadores humanos a travs de un panel de control, pero el gran
desafo es una autogestin de utilidad de computacin en el que las funciones
de control son automatizadas y responden a los cambios en tiempo real. El
diseo de polticas de gestin de recursos es complejo, debido al menos a tres
razones :

56
 1. Es heurstica. La gestin de recursos implica proyecciones bajo
incertidumbre y problemas de optimizacin que son NP-completo en su forma
general, lo que nos obliga a adoptar heursticas adaptadas a las necesidades y
configuraciones especficas. No existe una solucin de "talla nica".

2. Es dinmica. Las polticas de asignacin de recursos deben adaptarse a

las nuevas cargas de trabajo y las demandas en tiempo real.

3. Es orgnica y emergente. Las decisiones en las polticas de gestin deben

equilibrar las necesidades e intereses de los mltiples actores independientes,
por ejemplo, los proveedores de recursos y consumidores de recursos o
huspedes alojados. En general, la asignacin de recursos surge de decisiones
tomadas por cada uno de estos actores, y las complejas interacciones de esas
decisiones.

La estructura bsica de la poltica de gestin de recursos es comn a una

serie de visiones de computacin virtual en red, que abarca los centros de
gestin de datos, bancos de pruebas de red, sistemas de grid computing y
diversas utilidades disponibles en el mercado.

Mediante un balance adecuado de polticas y el mecanismos, estos sistemas

pueden basarse en la misma gestin de recursos de los sustratos subyacentes.

La mayor parte de las diferencias entre los enfoques de gestin tienen que
ver con cuestiones relacionadas con las polticas implementadas, o cuestiones
relacionadas con quines son los participantes y la cantidad de energa que
consumen, o diferentes supuestos de aplicacin que en ltima instancia tienen
poco impacto en los requisitos de gestin de los recursos disponibles. Estas
diferencias superficiales dejan abierta la posibilidad de una gestin comn. En
particular, a medida que aumentan las utilidades de red, el control basado en
arquitecturas abiertas se convierte en atractivo como base para la adjudicacin
de recursos flexible y adaptable.

57
8 OpenQRM : Plataforma Abierta de Gestin de Centros de Datos

En ste Captulo desarrollaremos la propuesta de arquitectura de gestin de

centros de datos utilizando el sistema centralizado OpenQRM.

Los centros de datos son por naturaleza ambientes personalizados y

complejos. Se requiere de considerable esfuerzo para su gestin y
mantenimiento. La complejidad se origina a partir del nmero de subsistemas
que intervienen y de la complejidad de cada subsistema. En un centro de datos
moderno, siempre hay un buen nmero de subsistemas que participan como
servidores fsicos, mquinas virtuales, diferentes sistemas operativos,
componentes, configuraciones y servicios de red; adems de un control de los
sistemas y los servicios, gestin fuera de banda y as sucesivamente. Resulta
conveniente la gestin centralizada de todos los diferentes aspectos en una sola
consola de administracin, que es exactamente el objetivo del marco
OpenQRM.

OpenQRM es una plataforma de cdigo abierto de nueva generacin para la

administracin de centros de datos. Su arquitectura totalmente conectable se
enfoca en el despliegue automtico, rpido y basado en dispositivos, monitoreo,
alta disponibilidad, computacin en la nube, copia de seguridad y
especialmente en apoyar y conformar tecnologas de virtualizacin mltiple.
OpenQRM es la nica solucin del mercado que unifica estos servicios en una
nica aplicacin lo que reduce de forma considerable los costes de estas
infraestructuras porque integra todos los elementos funcionales necesarios para
flexibilizar su almacenamiento, medir los consumos y proteger la integridad del
sistema con protocolos de alta disponibilidad. La plataforma de OpenQRM
integra en una nica consola de administracin la gestin tanto de las mquinas
fsicas cmo de las virtuales y permite automatizar y medir la actividad en los
centros de datos de una forma cmoda y segura. Provee una API bien definida
la cual puede ser usada para integrar herramientas de terceros como
complementos (plugins) adicionales.

El concepto principal detrs de OpenQRM es dividir los centros de datos en

subsistemas manejables. En OpenQRM cada subsistema se administra por
separado a travs de un plugin que proporciona la funcionalidad para su
gestin.

58
 OpenQRM crea interfaces automatizadas y genricas entre los diferentes
componentes a travs de su arquitectura de software modular. En realidad, el
servidor de base de OpenQRM est diseado para tener una sola funcin :
gestionar plugins. De esta manera nuevas caractersticas como el despliegue de
recursos adicionales, el almacenamiento y el tipo de virtualizacin se pueden
agregar a OpenQRM sin cambiar una sola lnea de cdigo en el servidor de
base. Mediante ste concepto se mantiene el servidor de base siempre pequeo,
esttico y robusto, pero tambin permite que varios desarrolladores trabajen en
diferentes plugins de forma paralela sin que estos interfieran entre s.

Figura 19. Interfaz de Gestin OpenQRM

Uno de los principios fundamentales de OpenQRM es proporcionar

interfaces genricas entre diferentes subsistemas en un entorno de TI de manera
escalable estandarizada, flexible y dinmica, evitando dependencias no
necesarias. Los subsistemas especficos se implementan por cualquiera de los
componentes de terceros mediante plugins o modulos de cdigo abierto o
comerciales, en la capa de abstraccin de OpenQRM. Para proporcionar
variedad y preferencias de administracin de sistemas especficas, OpenQRM
siempre trata de dar varias opciones con respecto a la implementacin de cada
subsistema. Un ejemplo de ello son las soluciones automatizadas de control
compatible e integrado en OpenQRM como nagios3, Zabbix y collectd, ms el
propio servicio de monitorizacin bsico de la plataforma.

Las diferentes tecnologas de virtualizacin y enfoques para unificarlas,

tratan de resolver el mismo problema de especficos (a veces incluso cerrados)
formatos de los discos duros virtuales. El hecho de que todas las tecnologas de

59
virtualizacin utilicen su propio formato de disco duro virtual hace que los
sistemas de migracin a otra tecnologa de virtualizacin, o incluso volver al
sistema fsico, sea una tarea compleja.

Para mitigar esta complejidad, OpenQRM proporciona una capa de

virtualizacin unificada que se encuentra en la parte superior de cada
tecnologa de virtualizacin y que permite realizar ajustes directamente en el
servidor OpenQRM. En OpenQRM las imgenes (servidor) se conectan
directamente desde el almacenamiento, a travs de la red, a las mquinas
virtuales de cualquier tipo. A travs de este OpenQRM la capa de
virtualizacin unificada admite la migracin sin problemas de los sistemas
fsicos a mquinas virtuales (P2V), de las mquinas virtuales de vuelta a los
sistemas fsicos (V2P) y tambin la migracin de la tecnologa de virtualizacin
de la A a la tecnologa de virtualizacin B (V2V).

OpenQRM tambin proporciona facilidades de gestin de los subsistemas de

almacenamiento mediante la integracin con varias tecnologas de
almacenamiento como NFS, iSCSI, AoE (Coraid), Equallogic, NetApp y ZFS.

8.1 Concepto, Diseo y Arquitectura

Una cuestin importante acerca de los centros de datos es : Estamos
tratando con "servicios" o "servidores"?

Es importante para nosotros que el hardware fsico especfico (o virtual)

siga trabajando o es ms importante mantener los servicios prestados por todo
el centro de datos en funcionamiento?

Los sistema de almacenamiento modernos vienen con soporte out of the

box de alta disponibilidad, escalabilidad y seguridad de los datos mediante
mejores arreglos de discos duros RAID permiten intercambio en caliente de
discos con fallas, sin interrupcin del sistema. Todos los archivos y datos
importantes en un centro de datos deben ser almacenados en ese tipo de
sistemas de almacenamiento para asegurar la disponibilidad de datos, su
integridad y para tener un nico lugar para copia de seguridad y restauracin.

La administracin de un data center con todos sus componentes es una tarea

que sobrecarga y excede las capacidades de una sola aplicacin. La
automatizacin y alta disponibilidad slo puede trabajar bien si todos los
componentes estn bien integrados y cooperan de una manera definida. El

60
resultado es an ms complejidad.

Para resolver este problema OpenQRM est basado en una arquitectura

estrictamente interconectada.

El servidor OpenQRM est separado en la base y los complementos y

actualmente la base ms o menos slo administra los complementos. La base
tambin provee el framework con el que los complementos interacten (por
ejemplo recursos, imagen, almacenamiento, objetos) pero todas estas
caractersticas de OpenQRM estn provistas por sus complementos.

Esto trae ciertos beneficios:

Desarrollo rpido dado que los desarrolladores pueden trabajar en

paralelo sobre diferentes complementos

Robustez mejorada dado lo robusto de la base, la cual no cambia mucho

ni con mucha frecuencia.

Fcil integracin con componentes de terceros a travs de una API de

complementos bien definida.

Errores en un complemento no daan al sistema base.

Menor complejidad debido a que el complemento administra slo su

propio ambiente.

Menos cdigo en el motor de base: menos cdigo significa menos errores.

Mejor escalabilidad debido a que sus complementos pueden ser

habilitados/inhabilitados sobre la marcha.

Los complementos son fciles de desarrollar gracias al framework de base

provisto.

Mediante una arquitectura nica, OpenQRM proporciona una capa de

abstraccin Datacenter-genrico que separa completamente los "servicios" de
los servidores fsicos o mquinas virtuales mediante el almacenamiento y el uso
de ellos directamente desde un almacenamiento centralizado robusto y de alta
disponibilidad. Dado que los tipos de almacenamiento tambin son modulares
en OpenQRM, puede utilizarse cualquier tipo de dispositivo de

61
almacenamiento externo o remoto.

En OpenQRM, todos los servicios provistos son integrables a una intefaz

centralizada mediante plugins o mdulos, permitiendo una capa de
abstraccin que facilita la gestin de los servicios sin necesidad de interactuar
de forma directa con los equipos involucrados en la prestacin del servicio.

8.2 Aprovisionamiento El modelo de Recursos OpenQRM

OpenQRM contiene una completa implementacin genrica de capa de
abstraccin y modelo de recursos que se ajusta al aprovisionamiento de
sistemas fsicos y mquinas virtuales de cualquier tipo. Lo primero que debe
hacerse para desplgar una imagen de servidor para un servidor fsico es la
integracin de sus recursos en el ambiente OpenQRM. La adicin de un nuevo
recurso fsico para OpenQRM se efecta a travs de una interfaz grfica de fcil
uso.

Mediante la utilizacin de "network-boot" (PXE) en el BIOS de los servidores

OpenQRM puede detectarlos automticamente y aadirlos a la intefaz de
gestin. Como se explica en detalle en el Captulo siguiente, el servidor
arrancar de forma automtica a travs de la red y aparecer como un nuevo,
recurso "inactivo" en la lista de recursos de OpenQRM.

A travs de los mdulos de virtualizacin de OpenQRM las mquinas

virtuales se crean y agregan a OpenQRM de manera similar a la de un servidor
fsico. Las mquinas virtuales de diferentes tipos son creadas a travs de la
interfaz VM-Manager que permite configurar diversos parmetros de VM,
como el nombre de la VM, la cantidad de memoria, el nmero de CPUs y la
conexin de red. La secuencia de arranque de mquinas virtuales se ajusta
entonces a "netboot" (PXE), lo que les permite ser aadidas a OpenQRM en la
misma forma que los sistemas fsicos. Aparecern en la lista de recursos
OpenQRM como nuevo, recurso inactivo del tipo de mquina virtual
especfica.

Todo el aprovisionamiento y la implementacin se controla en la seccin

Men de OpenQRM "Base" mediante un modelo de mquina o sistema. El
modelo de la mquina convierte los complejos flujos de trabajo de la
implementacin de un nuevo sistema de acuerdo con un grupo de parmetros
de configuracin, los requisitos y SLAs mediante una sola accin.

62
8.3 Capa de Almacenamiento
Dado que los mtodos de despliegue rpido de OpenQRM se basan en
sistemas de almacenamiento centralizados, constituyen un componente clave en
la red de gestin OpenQRM. La capa de almacenamiento en OpenQRM
proporciona al servidor la ubicacin de la imagen remota. Dependiendo del
tipo de almacenamiento esta ubicacin de imgen puede ser un NFS-export, un
LUN iSCSI, un volumen AOE o cualquier otro dispositivo que contenga un
contenido de raz del sistema de archivos vlido.

Al igual que en el caso de los servidores, el sistema de gestin

dealmacenamiento consta de recursos que ya est integrados y disponibles en
OpenQRM. Por lo tanto, lo primero que debe hacerse para crear un nuevo
almacenamiento en OpenQRM es agregar su recurso. Esto se puede hacer
mediante la implementacin de un servidor de almacenamiento de imgenes a
un recurso "inactivo" existente.

OpenQRM unifica y automatiza la administracin de los diferentes recursos

de almacenamiento mediante su interfaz de gestin de almacenamiento
integrado. Por lo tanto, durante la fase de diseo de OpenQRM, el equipo de
desarrollo dedico especial atencin a las acciones de almacenamiento frecuentes
y comunes requeridas en el centro de datos.

Todas estas acciones de almacenamiento son implementadas mediante un

plugin o mdulo de almacenamiento especfico para el tipo de tecnologa
utilizada, y expuestos a travs de un gestor de volmenes.

El rpido despliegue de OpenQRM tiene su origen en la gestin centralizada

de recursos a travs de la red y la facultad de iniciar los sistemas directamente
desde el almacenamiento remoto conectado a la plataforma de gestin. Para
asegurar la gestin de la red y de almacenamiento, y para asegurar que slo el
recurso dedicado a un equipo especfico pueda ser accedido desde una
ubicacin remota, OpenQRM se encarga automticamente de autenticar el
recurso y comprobar los permisos de acceso de los dispositivos que solicitan
acceso. Esto ocurre a travs del mdulo Auth-Hook proporcionado por el gestor
de almacenamiento. El hook de autenticacin incluye todos los parmetros de
configuracin y la informacin sobre el recurso que es utilizada por el plugin de
almacenamiento especfico (segn la tecnologa de almacenamiento utilizada)
para habilitar o deshabilitar el acceso.

63
8.4 Gestor de Virtualizacin
La virtualizacin se gestiona a travs de la interfaz de modelaje de mquinas
virtuales. El tipo de recurso especfico en la configuracin de la mquina
virtual indica la interfaz que utilizar OpenQRM para gestin. Por esta razn, el
host de virtualizacin debe estar integrado y disponible en OpenQRM. Esto se
puede hacer mediante la implementacin de un servidor host de virtualizacin
que est enlazado a un recurso de "inactivo" existente. En los casos en que sea
requerido gestionar un host de virtualizacin existente, ste puede ser
fcilmente integrado a travs del mdulo local-server.

No slo los tipos de almacenamiento, sino tambin los tipos de virtualizacin

son totalmente modulares en OpenQRM. A travs de sus plugin de API abierta
OpenQRM se integra con VMware ESX, VMware Server, Xen, KVM y Citrix
XenServer. Se ha aadido soporte para nuevas tecnologas de virtualizacin
como VirtualBox, OpenVZ y otros. Para ser capaz de manejar sin problemas
todos los diferentes tipos de mquinas virtuales, OpenQRM dispone una capa
en la parte superior de los mtodos de virtualizacin para unificar su gestin.
Las mquinas virtuales en OpenQRM pueden ser iniciadas en el entorno de
gestin, de la misma forma que los sistemas fsicos.

En un entorno OpenQRM, un hipervisor se convierte en "slo" un proveedor

de recursos, siendo responsable de hospedar el recurso de computacin virtual
seleccionado por el usuario.

De sta manera el sistema que se ejecuta en una mquina virtual tiene total
independencia de su Host hipervisor y puede migrado a otros hipervisores de
la misma o diferente tecnologa de virtualizacin o incluso de sistemas fsicos a
mquinas virtuales y viceversa. OpenQRM soporta P2V, V2P, y V2V;
permitiendo la migracin P2P sin ningn cambio en la configuracin de la
imagen provista para el sistema.

OpenQRM no slo puede gestionar diferentes tipos de tecnologas de

hipervisor sino que tambin puede implementar a travs de ellas el mecanismo
de despliegue, lo cual ofrece escalabilidad de la infraestructura de TI completa
debido a que el centro de datos puede crecer (y reducir) sus recursos
disponibles segn lo exigido, con slo aadir (o eliminar) hipervisores.

8.5 Monitorizacin
OpenQRM dispone de un cliente de monitorizacin, instalado

64
automticamente en todos los sistemas gestionados en la red OpenQRM a
travs de el sistema base, que incluye una utilidad de seguimiento. Este monitor
consiste en un shell script que enva las estadsticas al servidor OpenQRM a
travs del protocolo HTTPS. Las estadsticas incluyen datos de tiempo de
actividad, carga, modelo y nmero de CPUs, nmero de interfaces de red y el
trfico asociado, memoria, swap, etc. OpenQRM rene esas estadsticas y las
ingresa en su base de datos.

8.5.1 Nagios
Nagios es una herramienta de monitorizacin bien conocida, probada y
ampliamente utilizada, que est disponible para OpenQRM mediante un
mdulo integrable adicional. La combinacin de la monitorizacin mediante
Nagios y la gestin de errores automatizados, centro crea un entorno potente y
dinmico que reduce al mnimo el tiempo de inactividad de los sistemas y
servicios en un centro de datos moderno.

Figura 20. Interfaz Administrativa de Nagios

Nagios es una herramienta ampliamente adoptada, de cdigo abierto. El

servicio y el programa de monitoreo de la red est basado en el concepto de
cliente / servidor. El servidor Nagios obtiene informacin de seguimiento
mediante controles activos y pasivos. De esta forma puede comprobarse
activamente la disponibilidad de un sistema o servicio, de la misma forma en
que se recibe pasivamente la informacin sobre las pruebas que se ejecutan en
el sistema remoto. Los controles pasivos son iniciados por el cliente Nagios
(nrpe) que se ejecuta en los sistemas controlados por el servidor. La parte
cliente de Nagios est diseada en forma de mdulo integrable. Controles
activos y pasivos de nuevos servicios se pueden agregar fcilmente mediante la

65
creacin de plugins de OpenQRM para la interfaz cliente de Nagios y la
arquitectura del servidor Nagios base. El servidor Nagios se ejecuta en un
servidor web Apache y consiste en scripts de Shell y Perl, mezclados con
herramientas binarias ejecutadas a travs de la interfaz CGI. A intervalos
configurables, comprueba diversos servicios como SMTP, POP3, HTTP, NNTP,
etc., y proporciona la informaci recogida en una interfaz web. Tambin
supervisa los recursos del sistema, como la carga de CPU, el uso de memoria y
disco, procesos en ejecucin, registros, etc. y factores relevantes tales como la
temperatura de la CPU, placa base, o temperatura ambiente.

8.5.2 Collectd
Collectd es un programa residente (daemon) que recoge las estadsticas de
rendimiento del sistema peridicamente y proporciona mecanismos para
almacenar los valores en ficheros RRD. La integracin de collectd como un
plugin de OpenQRM proporciona una configuracin automtica del servidor
collectd y el cliente en todos los dispositivos gestionados dentro de la red
OpenQRM. Los Clientes collectd envan informacin estadstica al servidor
collectd principal que se ejecuta en el servidor OpenQRM. Los grficos
generados a partir de las estadsticas del sistema estn integrados en la interfaz
de usuario OpenQRM y tambin est disponible para los usuarios de sistemas
virtualizados gestionados.

8.5.3 Zabbix
Zabbix es una muy nueva herramienta de supervisin de sistemas que se
caracteriza por su gran capacidad de ampliacin y escalabilidad. Es una
solucin de monitorizacin de clase empresarial de cdigo abierto, tambin
disponible en OpenQRM como un plugin adicional.

Figura 21. Interfaz de Monitorizacin Zabbix

66
 El plugin Zabbix proporciona un servidor automatizado y la configuracin
de cliente para los dispositivos gestionados por OpenQRM. Los clientes Zabbix
son detectados automticamente por el servidor Zabbix a travs de la interfaz
de usuario personalizada integrada en el sistema y los controles de red que
puedan definirse.

8.6 Consideraciones respecto de la Seguridad

El entorno OpenQRM se basa en separar la gestin de servicios y el
almacenamiento disponible en una o ms redes. Para instalaciones de
produccin, se recomienda adaptar algunas consideraciones de seguridad para
proteger la informacin transmitida entre los diversos recursos gestionados y el
servidor base de OpenQRM.

Toda la comunicacin HTTP entre un navegador del cliente y la interfaz de

usuario OpenQRM Server es cifrada va SSL. Tambin la comunicacin interna
entre el Cliente OpenQRM (por ejemplo, para el envo de estadsticas) utiliza
ste protocolo.

Para mejorar la seguridad de la red, se recomienda la implementacin de un

cortafuegos con filtrado de paquetes entre la red de gestin y la red de
servicios. Las reglas del firewall se pueden adaptar dinmicamente de acuerdo
con los requisitos de trfico en la red de los recursos computacionales y de
almacenamiento.

Para mejorar an ms la seguridad de la red, puede implementarse el

etiquetado de VLAN a modo de proporcionar una separacin de la red fsica
completa para los sistemas gestionados en OpenQRM.

Para poner en prctica las reglas de firewall personalizadas para los

dispositivos administrados, se recomienda la creacin de ficheros de
configuracin o recipes que establecen las configuraciones de firewall
especficas segn los servicios ofrecidos por los dispositivos. Estos recipes se
pueden asignar manualmente a los dispositivos gestionados mediante la
interfaz de gestin (OpenQRM Puppet plugin) o se aplican de forma automtica
mediante el dispositivo de arranque y parada hooks

Para estar mejor informado acerca de los servicios que se ejecutan en las
instancias OpenQRM del centros de datos, puede utilizarse el mapping
automatizado de servicios a travs de la integracin nagios3. Este modo

67
especial de Nagios mostrar exactamente los servicios de red que estn
disponibles en el entorno administrado OpenQRM. Para obtener informacin
detallada de los servicios disponibles se recomienda utilizar los plugins collectd
y Zabbix disponibles en OpenQRM.

8.7 Desarrollo e Integracin de Mdulos Adicionales

La arquitectura modular de OpenQRM est diseada para apoyar
plenamente la integracin de nuevas funcionalidades. A travs de en un marco
esttico de gestin, se permite la integracin de diferentes plugins para su
utilizacin en paralelo. OpenQRM dispone de caractersticas de construccin y
embalaje (packing) de mdulos, modos de prueba para diversos niveles de
interaccin con el sistema base, depuracin, etc.

8.8 Recomendaciones : Crtica y propuestas de avance sobre la

solucin provista por OpenQRM
Nos encontramos en tiempos de cambios importantes en la definicin de
arquitecturas abiertas para la gestin de recursos informticos. OpenStack,
OpenNebula, Proxmox, entre otras iniciativas, se estn posicionando como
alternativas de cdigo abierto para la provisin y administracin de recursos
basados en Cloud.

OpenQRM constituye una aproximacin a la gestin de Centros de Datos

virtuales, que aun se encuentra en desarrollo y crecimiento continuo. A medida
que nuevos avances se realizan en ste sentido, se evidencia la necesaria
estandarizacin de procesos de gestin de recursos, que permitan una interfaz
comn de interaccin entre los diversos niveles de abstraccin definidos por las
soluciones de arquitectura abierta, a modo de que el modelo de capas analizado
en captulos anteriores pueda ser efectivamente implementado y que la gestin
de recursos fsicos geogrficamente distribuidos sea eficiente (compromiso de
eficacia).

Una de las mejoras a implementar en OpenQRM, seran los llamados Centros

de Datos Federados, que pongan a disposicin sus recursos en la red para ser
utilizados en la abstraccin de Centro de Datos virtuales, con activos
distribuidos, discutido previamente. Sera conveniente contar con un canal
comunicacin entre los Federados provisto en la misma plataforma, a modo de
que conjuntamente con informacin de negocio relevante, pueda gestionarse la

68
provisin, y consecuentemente la administracin de recursos ms adecuada
segn ubicacin geogrfica, poder de cmputo, tiempos de acceso, entre otros.

Ante la diversidad de soluciones de arquitectura abierta provistas, se hace

cada vez ms necesario definir mecanismos de interaccin que permitan la
transparente migracin de la informacin de gestin del recurso entre
diferentes plataformas de gestin, a modo de facilitar la implementacin de
CPDs virtuales y la federacin o agrupamiento de recursos geogrficamente
distribuidos.

69
9 Prueba de Concepto : Integracin de Gestin de VLANs

Como hemos indicado previamente, OpenQRM permite al integracin de

mdulos desarrollados por terceros, que conjuntamente con la arquitectura
abierta ofrecida por el sistema base, ofrecen la posibilidad de crear nuevas
funcionalidades de gestin y administracin de forma transparente, ampliable y
escalable. Las interfaces de programacin entre los mdulos y el sistema base,
se proporcionan bajo el esquema de Licencia GPL; de forma que el cdigo se
encuentra disponible para ser consultado o modificado segn las funcionalidad
requeridas por el Centro de Datos.

Como prueba de ello, hemos tomado el cdigo fuente de la Aplicacin HP

VLAN Administration y se han agregado funcionalidades especficas, como la
autenticacin mediante PAM (Pluggable Authentication Module) disponible en
Linux. Hemos igualmente integrado la utilidad ShellInABox, que permite la
ejecucin de un programa residente en el servidor de administracin, y ofrece
una interfaz web de lnea de comandos, a modo de gestionar de forma directa
mltiples comandos disponibles en el sistema desde una ubicacin remota; en
particular los comandos SNMP requeridos para la configuracin de Switches
HP Procurve.

En nuestro caso, hemos utilizado Apache versin 2.4 como servidor Web y el
paquete de desarrollo PHP versin 5.3.15. El sistema operativo utilizado fue
MacOS X Server versin 10.8.3.

Figura 22. Gestin web de VLANs en Switches HP ProCurve

9.1 HP VLAN Administration

La aplicacin HP VLAN Administration est disponible gratuitamente en la
web (SourceForge). Est escrita en lenguaje PHP y se ejecuta en el servidor de
gestin Web mediante CGI. La configuracin de los switches es realizada en
una interfaz grfica dispuesta por la aplicacin y accesible a travs de la web,

70
con diferentes mecanismos de autenticacin. Desde la interfaz grfica es
posible enviar diversos comandos SNMP, en mltiples versiones del protocolo,
para gestionar y administrar las VLAN de los switches HP Procurve.

9.2 ShellInABox
ShellInABox implementa un servidor web que puede exportar las
herramientas de lnea de comandos con un emulador de terminal basado en la
web. Este emulador es accesible a cualquier navegador web que tenga
habilitado JavaScript y CSS, y no requiere ningn tipo de plugins de
navegacin adicionales.

9.3 Integracin en OpenQRM y Escalabilidad

Tanto la aplicacin HP VLan Administration como ShellInABox pueden
ser integradas al sistema OpenQRM mediante la utilidad de desarrollo y
empaquetamiento provista por los desarrolladores. Esta utilidad encapsula el
cdigo de ambas aplicaciones bajo el entorno de ejecucin, de forma que
puedan ser accedidas desde la interfaz Web base de OpenQRM como un
mdulo activable segn el requerimiento del administrador.

71
Conclusiones

Los centros de datos son por naturaleza ambientes personalizados y

complejos. Se requiere de considerable esfuerzo para su gestin y
mantenimiento. La complejidad se origina a partir del nmero de subsistemas
que intervienen y de la complejidad de cada subsistema. En un centro de datos
moderno, siempre hay un buen nmero de subsistemas que participan como
servidores fsicos, mquinas virtuales, diferentes sistemas operativos,
componentes, configuraciones y servicios de red; adems de un control de los
sistemas y los servicios, gestin fuera de banda y as sucesivamente. Resulta
conveniente la gestin centralizada de todos los diferentes aspectos en una sola
consola de administracin.

Las aplicaciones de centros de datos implican cada vez ms el acceso

conjuntos masivos de informacin, minera de datos (Data Mining) en tiempo
real y transmisin en streaming que imponen grandes exigencias a la
infraestructura de procesamiento, conectividad y almacenamiento.

Varias fuerzas estn dando forma al paisaje del centro de datos y esperamos
que los futuros centros de datos sean mucho ms que simplemente versiones
ms grandes de las que hoy existen. Estas tendencias emergentes muestran que
los centros de datos evolucionan hacia sistemas distribuidos en infraestructuras
virtualizadas de varias capas, que presentan una serie de retos difciles.

En el presente trabajo hemos definido un modelo de capas para este tipo de

centros de datos y se proporciona un anlisis detallado del estado de la tcnica
y los nuevos desafos en la gestin y administracin del almacenamiento, los
recursos computacionales y las redes.

Hemos propuesto una Arquitectura Abierta para la gestin y administracin

de recursos en Centros de Datos. El mbito de pruebas se ha limitado a integrar
diversas herramientas de gestin en una plataforma nica de administracin, a
modo de probar que la arquitectura abierta de OpenQRM permite conjugar
diversas funcionalidades en una misma interfaz de gestin, de forma
transparente, dinmica y escalable.

La utilizacin de una arquitectura abierta facilita la gestin y administracin

de recursos en centros de datos, permitiendo que nuevas funcionalidades
puedan ser agregadas sin interferir con los procesos ya implementados;

72
disminuyendo de forma considerable los costes asociados sin poner en riesgo la
operatividad y los servicios provistos.

La plataforma de gestin OpenQRM provee de la flexibilidad y la

escalabilidad necesaria para los mltiples servicios ofrecidos por los centros de
datos modernos, permitiendo la inclusin de nuevos servicios a medida y la
funcionalidad de soluciones de gestin previamente implementadas, mediante
su inclusin en la plataforma a travs de mdulos o plugins.

Observamos que conjuntamente con OpenQRM, existen otras soluciones que

ofrecen la gestin de recursos en Centros de Datos, desde la administracin de
servidores fsicos y equipos de red; hasta recursos basados en Cloud. Ante la
diversidad de soluciones de arquitectura abierta provistas, se hace cada vez
ms necesario definir mecanismos de interaccin que permitan la transparente
migracin de la informacin de gestin del recurso entre diferentes plataformas
de gestin.

73
Bibliografa

[1] Moore J., Chase J., Farkas K., Ranganathan P., 2009

Datacenter Workload, Monitoring, Analysis and Emulation

Duke University, Department of Computer Science

Hewlett Packard Labs, Internet Systems and Storage Lab.

[2] Greenberg A., Lahiri P., Maltz D., Patel P., Sengupta S., 2008

Towards a Next Generation Datacenter Architecture : Scalability

and Commoditization.

Microsoft Research, Redmond VA

[3] Kiriha J., Nishihara M., 2013

Survey on Datacenter Networking Technologies

Invited Paper, IEICE Trans Commun, VOL E96-B, No. 3

[4] Chase J., Grit L., Irwin D., Marupadi V., Shivam P., Yumerefendi., 2009

Beyond Virtual Datacenters : Toward and Open Resource Control

Architecture

Duke University, Department of Computer Science

[5] Walli S., Ginn D.,Von Rotz V., 2005

74
 The Growth of Open Source Software in Organizations

Optaros Publications and Thought Leadership, Optaros

[6] OpenQRM Enterprise Documentation, 2013

The OpenQRM Datacenter Management Platform

OpenQRM Enterprise GmbH, Germany

[7] West J., Gallagher, S., 2005

Patterns of Open Innovation in Open Source Software

College of Business, San Jose State University

College of Business, James Madison University

[8] Chesbrough H., Vanhaberveke W., Joel W., 2006

Open Innovation : Researching a New Paradigm

Oxford University Press

[9] Dutt D., Duda K., Argawal P, Kreeger L., Sridhar T, Bursel M., 2013

VXLAN: A Framework for Overlaying Virtualized Layer 2 Networks

over Layer 3 Networks

Internet Engineering Task Force (IETF), Networking Group

[10] Maurer M., Brandic I., Sakellariou R., 2013

Adaptive Resource Configuration for Cloud Infrastructure Mgmt.

Future Generation Computer Systems Journal, ELSEVIER

75