universidad politécnica de madrid escuela técnica...
TRANSCRIPT
Universidad Politécnica de Madrid Escuela Técnica Superior de Ingenieros de Telecomunicación
DESARROLLO DE PROPUESTA DE ARQUITECTURA ABIERTA PARA LA GESTIÓN
DE CONFIGURACIÓN Y ADMINISTRACIÓN DE
RECURSOS EN CENTROS DE DATOS
TRABAJO FIN DE MÁSTER
Roberto Saavedra Neira
2013
Universidad Politécnica de Madrid Escuela Técnica Superior de Ingenieros de Telecomunicación
Máster Universitario en Ingeniería de Redes y Servicios Telemáticos
TRABAJO FIN DE MÁSTER
DESARROLLO DE PROPUESTA DE ARQUITECTURA ABIERTA PARA LA GESTIÓN
DE CONFIGURACIÓN Y ADMINISTRACIÓN DE
RECURSOS EN CENTROS DE DATOS
Autor Roberto Saavedra Neira
Director Prof. David Fernández Cambronero
Departamento de Ingeniería de Sistemas Telemáticos
2010
i
Resumen
Los centros de datos son una parte clave de la infraestructura sobre la que se
construyen gran variedad de servicios de tecnología de la información. Como
los centros de datos siguen creciendo en tamaño y complejidad, es conveniente
entender los aspectos de su diseño que son dignos de llevar adelante, así como
las deficiencias y los retos existentes o futuros que tendrían que abordarse.
En los últimos años, las tecnologías y los mercados relacionados con los
centros de datos han sido objeto de rápidos cambios y crecimiento. Los centros
de datos están jugando un papel importante en la implementación de
Infraestructura TIC y en la promesa para convertirse en una plataforma común
para casi todas las infraestructuras sociales. A pesar de que la investigación se
han centrado en las tecnologías 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 tecnologías, examinamos los esfuerzos de
investigación, desarrollo y recientes resultados, de acuerdo con la taxonomía de
un centro de datos.
De acuerdo con muchos cambios, tales como el número de usuarios, el
volumen de los datos analizados / procesados, y la complejidad de la lógica de
servicio proporcionado, el papel y la configuración de los centros de datos han
cambiado drásticamente. Se han vuelto ahora más abiertos y basados en
tecnologías de servicios, a una mayor escala, más eficientes energéticamente y
más ampliamente distribuidos para manejar la mezcla de gran número de
clientes atendidos.
Tenemos la visión de la evolución del centro de datos en las entidades físicas
propias de las infraestructuras potencialmente tercerizadas, virtualizadas y
distribuidas geográficamente que aún 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 análisis detallado del estado de la técnica y los nuevos desafíos
en la gestión y administración del almacenamiento, las redes, la gestión y los
aspectos térmicos y de energía.
iii
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.
v
Índice general
Resumen .................................................................................................................................. i
Abstract .................................................................................................................................. iii
Índice general ......................................................................................................................... v
Índice de figuras .................................................................................................................. vii
Siglas ...................................................................................................................................... ix
1 Introducción ...................................................................................................................... 1
2 Organización y problemas del centro de datos ........................................................... 3
2.1 Organización física ................................................................................................... 3
2.2 Almacenamiento e infraestructura de red ............................................................. 4
2.3 Infraestructura de gestión ........................................................................................ 5
2.4 Infraestructura eléctrica y refrigeración ................................................................ 7
2.5 Los principales problemas del centro de datos .................................................... 8
3 Evolución de los Centros de Datos .............................................................................. 11
4 Infraestructura de Red en Centros de Datos .............................................................. 14
4.1 El stack Ethernet ...................................................................................................... 14
4.2 Desafíos de las Redes en Centros de Datos ......................................................... 18
4.3 VXLan : Superando el límite de VLans ................................................................ 23
5 Almacenamiento en los Centros de Datos ................................................................. 29
5.1 Conceptos básicos de almacenamiento ................................................................ 29
5.2 Almacenamiento en discos de estado sólido e híbridos .................................... 33
5.3 Desafíos en el almacenamiento ............................................................................. 35
6 Gestión de la configuración en los centros de datos ................................................. 38
6.1 Gestión del ciclo de vida ........................................................................................ 38
6.2 Marcos operacionales de gestión .......................................................................... 40
6.3 Almacenamiento de datos de gestión .................................................................. 41
6.4 Desafíos en la Provisión de Servicios ................................................................... 45
6.5 Desafíos en la Gestión de Procesos ...................................................................... 47
vi
7 Requisitos de la Gestión de Recursos en Centros de Datos ..................................... 50
7.1 Monitorización ........................................................................................................ 53
7.2 Análisis de Información en Tiempo Real ............................................................ 55
7.3 Evolución de las Arquitecturas abiertas en la Gestión de Recursos ................ 56
8 OpenQRM : Plataforma Abierta de Gestión de Centros de Datos ......................... 58
8.1 Concepto, Diseño y Arquitectura ......................................................................... 60
8.2 Aprovisionamiento – El modelo de Recursos OpenQRM ................................ 62
8.3 Capa de Almacenamiento ...................................................................................... 63
8.4 Gestor de Virtualización ........................................................................................ 64
8.5 Monitorización ........................................................................................................ 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 Integración de Módulos Adicionales ............................................. 68
9 Prueba de Concepto : Integración de Gestión de VLANs ........................................ 70
9.1 HP VLAN Administration ..................................................................................... 70
9.2 ShellInABox ............................................................................................................. 71
9.3 Integración en OpenQRM y Escalabilidad .......................................................... 71
Conclusiones ......................................................................................................................... 72
Bibliografía ............................................................................................................................ 73
vii
Índice de figuras
Figura 1. Infraestructura de Datacenter y Gestión de TI .................................................. 3 Figura 1. Arquitectura de Red Convencional vs. Arquitectura de N-aria de
Topología Fat Tree ....................................................................................................................... 5 Figura 3. Topología de Red : Nivel de Core, Agregación y Acceso ................................ 6 Figura 4. Sistema de Enfriamiento por A/C tipo Crac-Up (Suelo Técnico) .................. 7 Figura 5. La Gestión de Recursos en Centros de Datos .................................................... 9 Figura 6. Modelo de Conceptual de Capas : Infraestructura Virtual e Infraestructura
Física ............................................................................................................................................ 12 Figura 7. Ubicación del Etiquetado VLAN en una trama Ethernet .............................. 15 Figura 8. Flujo de Información del Protocolo SCTP ........................................................ 17 Figura 9. Bits de ‘Clase de Servicio’ en una Trama Ethernet ......................................... 21 Figura 10. Ubicación del Campo VXLAN ID (24 Bits) .................................................... 24 Figura 11. Encapsulamiento del encabezado VXLAN .................................................... 25 Figura 12. Características de diversas Interfaces de Almacenamiento ........................ 30 Figura 13. Memoria de Núcleo Magnético (a) y Ferro-Eléctrica (b) ............................. 33 Figura 14. Controlador de Memoria Flash ....................................................................... 35 Figura 15. Componentes de CIM (Common Information Model) ................................ 42 Figura 16. Gestión de Infraestructura : Capa de Control (Underware) ........................ 51 Figura 16. Integrated Data Center Infrastructure Management .................................... 53 Figura 17. Gestión de IT y Servicios de Negocio (DCIM) .............................................. 54 Figura 18. Interfaz de Gestión OpenQRM ........................................................................ 59 Figura 19. Interfaz Administrativa de Nagios ................................................................. 65 Figura 20. Interfaz de Monitorización Zabbix ................................................................. 66 Figura 21. Gestión web de VLANs en Switches HP ProCurve .................................... 70
ix
Siglas
AC (Altern Current) : Corriente Alterna
AOE (ATA over Ethernet) : ATA sobre Ethernet
ATA (Advanced Technology Attachment) : Tecnología Avanzada de Adición
BMC (Board Main Controller) : Controlador Principal de Placa Base
CDA (Common Data Access) : Acceso Común de Datos
CFS (Cluster File System) : Sistema de Ficheros en Clúster
CGI (Common Gateway Interface) : Interfaz de Pasarela Común
CIM (Common Information Model) : Modelo Común de Información
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 Gestión de Configuración
CoS (Class of Service) : Clase de Servicio
CPD : Centro de Procesamiento de Datos
CRC (Cyclic Redundancy Check) : Chequeo de Redundancia Cíclica
CSS (Cascading Style Sheets) : Hojas de Estilo en Cascada
CST (Central Superior Tree) : Arbol de Expansión Superior Central
DAS (Directly Attached Storage) : Almacenamiento Directo Adjunto
DC (Direct Current) : Corriente Directa
DCIM (Datacenter Infrastructure Management) : Gestión de Infraestructura de CPD
DMTF (Distributed Management Task Force) : Grupo de Trabajo de Gestión Distribuída
DoS (Denial of Service) : Denegación de Servicio
DVDC (Distributed Virtual Data Center) : CPD Virtual Distribuído
E/S : Entrada / Salida
x
EC2 (Elastic Cloud 2) : Nube Elástica 2 de Amazon
ECMP (Equal Cost Multi-Path) : Multi-trayecto de Coste Equivalente
EMP (External Management Packages) : Paquetes de Gestión Externos
FC (FibreChannel) : Tecnología de Comunicación por Canal de Fibra
FCIP (FibreChannel over IP) : FC sobre Protocolo Internet
FeRAM (Ferro-Electric Random Access Memory) : Memoria de Acceso Aleatorio Ferro-Eléctrica
FPGA (Field Programmable Grid Array) : Arreglo de Malla Programable en Campo
FTL (Flash Translation Layer) : Capa de Traducción 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 Anfitrión
IANA (Internet Assigned Numbers Authority) : Autoridad de Asignación de Números 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 – Ratón
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 Volúmenes Lógicos
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 Magnética
xi
NAND (Negated AND) : Compuerta Lógica de Negación AND o ‘Not AND’
NAS (Network Attached Storage) : Almacenamiento Adjunto a Red
NAT (Network Address Translation) : Traducción de Dirección 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 volátil
OOB (Out-of-Band) : Comunicaciones Fuera de Banda
P2P (Physical to Physical) : Servidor físico a Servidor físico
P2V (Physical to Virtual) : Servidor físico a Servidor virtual
PaaS (Platform as a Service) : Plataforma como Servicio
PAM (Pluggable Authentication Module) : Módulo Conectable de Autenticación
PByte (PetaByte) : 1015 Bytes
PCI (Peripheral Component Interconnect) : Interconexión de Componentes Periféricos
PCM (Phase Changing Memory) : Memoria de Cambio de Fase
PDU (Power Distribution Unit) : Unidad de Distribución de Energía
PHY (Physical Layer) : Nivel Físico
PIL (Physical Infrastructure Layer) : Capa de Infraestructura Física
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 Ejecución 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 Ingeniería de Tráfico
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 Adición Serial
xii
SATA (Serial Advanced Technology Attachment) : Tecnología Avanzada de Adición Serial
SCSI (Small Computer System Interface) : Interfaz de Sistema de Ordenadores Pequeños
SCTP (Streaming Control Transmission Protocol) Protocolo de Control de Transmisión 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 Señalización Número 7
SSD (Solid State Disk) : Disco de Estado Sólido
STP (Spanning Tree Protocol) : Protocolo de Arbol de Expansión (Switches)
TCP (Transmission Control Protocol) : Protocolo de Control de Transmisión
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 Alimentación Ininterrumpida
USB (Universal Serial Bus) : Bus Serial Universal
UWB (Ultra Wide Band) : Banda Ultra Ancha
V2P (Virtual to Physical) : Servidor virtual a Servidor físico
V2V (Virtual to Virtual) : Servidor virtual a Servidor virtual
VC (Virtual Cluster) : Clúster Virtual
VDC (Virtual Datacenter) : CPD Virtual
VICL (Virtual Infrastructure Coordination Layer) : Capa de Coordinación de Infraestructura Virtual
VIL (Virtual Infrastructure Layer) : Capa de Infraestructura Virtual
VLAN (Virtual Local Area Network) : Red de Área Local Virtual
xiii
VM (Virtual Machine) : Máquina Virtual
VNI (Virtual Lan Network ID) : Identificador de VLAN
VPN (Virtual Private Network) : Red Privada Virtual
VR (Voltage Regulator) : Regulador de Voltaje / Tensión
VTEP (Virtual Tunnel End-point) : Extremo final de Túnel Virtual
W3C : World Wide Web Consortium
WBEM (Web-based Enterprise Management) : Gestión Empresarial basada en Web
WSMAN (Web Services Management) : Gestión de Servicios Web
ZFS (Sun Microsystems ‘Zettabyte Filesystem’) : Sistema de Ficheros ‘Zettabyte’ de Sun Microsystems
Zipf (George Kingsley Zipf Empirical Law) : Ley Empírica de Estadísticas Matemáticas de George Kingsley Zipf
1
1 Introducción
Los centros de datos son la columna vertebral de una amplia variedad de
servicios ofrecidos a través de Internet como Web-hosting, comercio electrónico,
redes sociales, y una variedad de servicios más generales, tales como el
software como servicio (SaaS), plataforma como servicio (PaaS ) y cloud
computing. Algunos ejemplos de estas plataformas de servicios genéricos son
Microsoft Azure, Google App Engine, Amazon EC2 y Oracle Grid Engine. La
virtualización es la clave para ofrecer muchos de estos servicios y se está
utilizando cada vez más en los centros de datos para lograr una mejor
utilización de los servidores y la asignación de recursos más flexible. Sin
embargo, la virtualización también hace que muchos aspectos de la gestión del
centro de datos más desafiante.
A medida que la complejidad, la variedad y la penetración de estos servicios
crece, los centros de datos seguirá creciendo y proliferando. Varias fuerzas
están dando forma al paisaje del centro de datos y esperamos que los futuros
centros de datos sean mucho más que simplemente versiones más grandes de
las que hoy existen. Estas tendencias emergentes, que se explican con más
detalle en el Capítulo 3, muestran que los centros de datos evolucionan hacia
sistemas distribuidos en infraestructuras virtualizadas de varias capas, que
presentan una serie de retos difíciles.
En el presente trabajo, ofrecemos una cobertura tutorial de una serie de
nuevos problemas en el diseño y la gestión de grandes centros de datos. En
particular, consideraremos un modelo de capas de los centros de datos y
discutiremos aspectos de almacenamiento, redes, gestión, y problemas térmicos
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 técnicas de virtualización, migración de
máquinas virtuales y programación en entornos virtualizados.
La organización del trabajo es la siguiente. En el Capítulo 2 se analiza la
organización de un centro de datos y señala varias áreas difíciles en la gestión
del centro de datos. En el Capítulo 3 se discuten las tendencias emergentes en
2
centros de datos y las nuevas cuestiones planteadas por ellos. Las siguientes
secciones se discuten temas específicos en detalle, incluyendo almacenamiento,
redes, gestión de energía y problemas térmicos. Por último, se propone una
arquitectura abierta para la gestión de la configuración de elementos de red,
basada en software de código abierto y se presenta una prueba de concepto. En
particular, se abordan las capacidades y características de la herramienta
OpenQRM, como plataforma de gestión que combina las funcionalidades
requeridas para la eficaz administración y gestión de la infraestructura del
centro de datos.
3
2 Organización y problemas del centro de datos
2.1 Organización física 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 estándar 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 módulos "para montaje en rack" activos insertados
horizontalmente en los bastidores. El espesor de estos módulos se mide
utilizando una unidad llamada "U", que es de 45 mm (aproximadamente 1,8
pulgadas). Una gran mayoría de los servidores de uno o dos sockets se pueden
adaptar al tamaño 1U.
Un rack estándar puede tomar un total de 42 equipos de 1U cuando está
completamente lleno. La sofisticación del bastidor puede variar en gran
medida. Las características adicionales pueden incluir la distribución de
potencia por rack, una función de KVM (teclado - video - mouse), aire
acondicionado a nivel de bastidor o refrigeración líquida, y tal vez incluso una
unidad de gestión de nivel de rack.
Figura 1. Infraestructura de Datacenter y Gestión de TI
Para una mayor eficiencia en su funcionalidad, los servidores pueden ser
alojados en un chasis autónomo que a su vez se desliza en el bastidor. El chasis
proporciona ranuras de tamaño estándar que se podría insertar activos
modulares (generalmente conocido como Blades). Un solo chasis puede
albergar hasta 16 servidores 1U, proporcionando así una capacidad teórica de
rack de 96 activos modulares.
El aumento sustancial en la densidad de servidores alcanzable mediante el
4
uso de Blades tiene un correspondiente incremento en el consumo de energía
por rack, que a su vez pueden impactar de manera importante la
infraestructura de distribución de energía. En particular, muchos centros de
datos están diseñados 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 térmica. La
infraestructura de refrigeración puede ser incapaz de manejar la carga térmica
que se produce en la operación 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 físicos utilizados. El almacenamiento también
se puede proporcionar en bloques más pequeñas 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 típicamente cuatro tipos de accesos de red, y
potencialmente podría utilizar cuatro tipos diferentes de redes físicas.
Mediante una arquitectura cliente / servidor de red se permite el acceso externo
a los centros de datos, utilizando necesariamente una tecnología de productos
elementales como el cable Ethernet o Fibra Optica. El acceso al almacenamiento
tradicionalmente ha sido proporcionada por canal de fibra, pero también podría
utilizar Ethernet o Infiniband. La red que se utiliza para la gestión también es
típicamente Ethernet pero puede usar cableado separado o existir como una
"banda lateral" en la red convencional.
Las redes de almacenamiento y de propósito general suelen seguir
configuración similar. Para los servidores Blade montados sobre un chasis, éste
último proporciona un conmutador o “switch” a través de la cual todos los
servidores del chasis se conectan a servidores externos. Estos switches
generalmente disponen de conectividad dúplex para la fiabilidad y se pueden
organizar para carga compartida.
5
Figura 2. Arquitectura de Red Convencional vs. Arquitectura de N-aria de Topología Fat Tree
A fin de mantener la red manejable, la topología general es básicamente un
árbol con conectividad total en el nivel raíz. 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 comunicación entre dos servidores en diferentes chasis debe ir a
través de, al menos, tres switches. Dependiendo del tamaño del centro de datos,
los múltiples switches pueden ser conectados en una malla completa, o a través
de uno o más 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 están
diseñados para una relación de exceso de específica, ya que proporcionar un
ancho de banda de bisección completo es por lo general no viable. Por ejemplo,
20 servidores, cada uno con conectividad Ethernet de 1 Gbps pueden compartir
una sola conexión Ethernet de enlace ascendente de 10 Gbps para una relación
de exceso de 2,0. Esto puede ser problemático si la asignación de carga de
trabajo es tal que existe una comunicación no local sustancial. Como el
almacenamiento se ofrece tradicionalmente en una torre de almacenamiento
por separado, todo el tráfico de almacenamiento generalmente atraviesa el
enlace ascendente del chasis en la red de almacenamiento. Como los centros de
datos crecen en tamaño, una arquitectura de red más escalable se hace
necesaria.
2.3 Infraestructura de gestión Cada servidor por lo general lleva un controlador de administración llamado
BMC (controlador de gestión de placa base). La red de gestión termina en el
BMC de cada servidor. Cuando la red de gestión se implementa como una red
de "banda lateral", no se requieren switches adicionales. De lo contrario, se
requiere un conmutador de gestión en cada chasis / bastidor para soportar la
6
comunicación externa. Las funciones básicas de la BMC incluyen el monitoreo
de varios sensores de hardware, gestión de hardware diferentes y alertas de
software, arrancar y apagar el servidor, el mantenimiento de los datos de
configuración de varios dispositivos y controladores, y proporcionar
capacidades de administración remota. Cada chasis o bastidor pueden integrar
en sí mismo un controlador de administración de nivel superior que se
comunica con el controlador de nivel inferior.
Figura 3. Topología de Red : Nivel de Core, Agregación y Acceso
La gestión de la configuración es un término bastante genérico que puede
referirse a la gestión de la configuración de los parámetros de una variedad de
objetos que son de interés en la utilización eficaz de la infraestructura del
sistema informático y de dispositivos individuales, hasta servicios complejos
que se ejecutan en grandes grupos en red. Parte de esta gestión pertenece
claramente al controlador de gestión de placa base (BMC) o de la cadena de
gestión de nivel superior correspondiente.
Esto a menudo se conoce como gestión fuera de banda (OOB), ya que se
realiza sin intervención de la CPU principal o el sistema operativo. Otras
actividades pueden ser más apropiadas para su administración en banda
lateral, y pueden ser realizadas por la CPU principal, en el sistema operativo, o
en el middleware. La gestión de nivel superior puede ejecutarse en sistemas
separados que tienen tanto fuera de banda como dentro de banda. En un
servidor, las funciones más críticas 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 gestión es necesariamente OOB.
7
2.4 Infraestructura eléctrica y refrigeración Incluso los centros de datos de tamaño medio pueden tener un consumo de
energía máximo de varios megavatios. Para tales cargas de energía, se hace
necesario utilizar suministros de alta tensión (por ejemplo, 15 KV en tres fases)
conjuntamente con un sistema de transformación en las instalaciones a 240V a
través de un sistema de alimentación ininterrumpida (UPS ). La unidad UPS
debe convertir AC a DC para cargar sus baterías y luego convertir DC a AC en
el extremo de salida. Dado que la unidad UPS se encuentra directamente en el
circuito de alimentación, se puede seguir suministrando potencia de salida
ininterrumpida en caso de pérdida de potencia de entrada. La salida de la UPS
(por lo general 240/120 V, en sola fase) se encamina a la unidad de distribución
de energía (PDU) que, a su vez, suministra alimentación a los servidores
instalados en bastidor o chasis de Blades individuales. A continuación, la
potencia es reducida, convirtiendo la corriente alterna (AC) en corriente directa
(DC) parcialmente regulada, a fin de producir los típicos ±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 tensión (VR) deben convertirla en
diversos valores de voltaje, según las exigencias de diseño del servidor.
Cada una de estas etapas de conversión y distribución de energía resulta en
pérdida de potencia, con algunas etapas que muestran eficiencia en un rango de
85 - 95%. Por lo tanto, no es sorprendente que la eficiencia de energía
acumulada en el voltaje final de la placa base de servidores y equipos de
almacenamiento y red es sólo el 50% o menos (sin considerar la refrigeración,
iluminación y otros usos de energía auxiliar). Existe por lo tanto un margen
importante para lograr una mayor eficiencia de energía mediante un mejor
diseño de transformación y distribución de energía.
Figura 4. Sistema de Enfriamiento por A/C tipo Crac-Up (Suelo Técnico)
La infraestructura de refrigeración en un centro de datos puede ser muy
compleja y costosa, implicando varias unidades de aire acondicionado que
8
requieren plantas enfriadoras, ventiladores y sistemas de recirculación de aire.
La evolución de las tecnologías de refrigeración tienden a enfatizar un
enfriamiento más localizado, o tratar de simplificar la infraestructura de
refrigeración. Los bastidores de equipos de red, almacenamiento y servidores
generalmente se colocan en una cámara de sobrepresión elevada, dispuestos en
forma alternada orientados hacia atrás, creando los llamados pasillos fríos y
calientes. El aire frío es forzado hacia arriba en los pasillos a través del suelo
técnico, y los ventiladores de los servidores o chasis lo impulsan a través 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
recirculación. Esta configuración básica no es costosa, pero también puede crear
puntos calientes irregulares, ya sea debido a un enfriamiento desigual o la
mezcla de aire caliente y frío.
2.5 Los principales problemas del centro de datos Las aplicaciones de centros de datos implican cada vez más el acceso
conjuntos masivos de información, minería de datos (Data Mining) en tiempo
real y transmisión en ‘streaming’ que imponen grandes exigencias a la
infraestructura de procesamiento, conectividad y almacenamiento. El acceso
eficiente a grandes cantidades de datos requiere no sólo los sistemas de
archivos de alto rendimiento, sino también de tecnologías de almacenamiento,
tales como medios de almacenamiento de estado sólido (SSD). La transmisión
de grandes cantidades de datos requiere de redes de alta velocidad y baja
latencia. En las aplicaciones en clúster, la comunicación entre procesos (IPC) a
menudo implica mensajes más pequeños pero con requisitos de muy baja
latencia.
Estas aplicaciones también 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 física, como Ethernet, que
concentrarlos en un solo equipo. Sin embargo, esto requiere de capacidades
QoS sofisticadas que no están necesariamente disponibles en los protocolos
existentes.
La Gestión de la configuración es un componente vital para el buen
funcionamiento de los centros de datos, pero no ha recibido mucha atención en
la literatura. Se requiere gestión de la configuración en múltiples niveles, que
van desde los servidores a las troncales de interconexión para todo el centro de
9
datos. Los entornos virtualizados introducen temas de gestión de la
configuración a un nivel lógico (en lugar de físico). A medida que la
complejidad de servidores, entornos operativos y las aplicaciones aumenta, la
gestión eficaz en tiempo real de grandes centros de datos heterogéneos se hace
muy compleja. Estos desafíos y algunos enfoques actuales se discutirán
posteriormente.
Figura 5. La Gestión de Recursos en Centros de Datos
El aumento del tamaño de los centros de datos no sólo se traduce en altos
costos de servicio, sino que también conduce a importantes desafíos en la
gestión energética y térmica. Se estima que el consumo de energía total de los
centros de datos, como porcentaje del consumo total de energía de EE.UU. se
duplicó entre 2000 y 2007, y se duplicará de nuevo en 2013. Los altos costos de
servicios públicos y el impacto ambiental de este aumento son razones
suficientes para abordar el consumo de energía. Adicionalmente, el consumo
elevado de energía también se traduce en la corriente sostenible, la potencia, y
las densidades térmicas, y el uso eficiente del espacio del centro de datos. Tratar
los problemas energéticos y térmicos requiere de técnicas de control de potencia
y de refrigeración en múltiples niveles (dispositivo, sistema, recinto, etc.) y a
través de múltiples dominios (por ejemplo, hardware, sistema operativo y de
gestión). La gestión de la energética y térmica 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 tamaño y la criticidad, se
convierten cada vez más en atractivos objetivos de ataque, por lo que una
vulnerabilidad aislada puede afectar a un gran número de clientes y / o
grandes cantidades de datos sensibles. Así, un desafío a la seguridad
10
fundamental para los centros de datos es encontrar mecanismos viables que
permitan reducir el crecimiento de la vulnerabilidad conjuntamente con su
tamaño. Básicamente, la seguridad debe implementarse de forma que ningún
compromiso pueda proporcionar acceso a un gran número de máquinas o gran
cantidad de datos. Otra cuestión 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 podrían muy bien ser los que comparten la misma
infraestructura física para sus fines comerciales.
Por último, las propias técnicas básicas de virtualización aumentan las
vulnerabilidades desde la flexibilidad que ofrecen y ello puede ser aprovechado
fácilmente para la interrupción y la denegación de servicio. Por ejemplo,
cualquier vulnerabilidad en el mapeo de atributos de nivel VM para el sistema
físico puede ser explotado para sabotear todo el sistema.
11
3 Evolución 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 más
complejas.
Por ejemplo, al igual que la virtualización permite la consolidación y ahorro
de costes en un centro de datos, la virtualización de los centros de datos podría
permitir a un nivel mucho más alto de agregación. Esta idea lleva a la
posibilidad de "recursos externos" en centros de datos que permiten a una
organización para operar un gran centro de datos sin tener que poseer
infraestructura física. La computación de la nube, de hecho, proporciona
exactamente tal capacidad, excepto que en la nube, los recursos se obtienen
generalmente de forma dinámica por períodos cortos y la gestión subyacente de
estos recursos está totalmente oculta para el usuario. Los suscriptores de los
centros de datos virtuales suelen solicitar acuerdos a más largo plazo y mucho
más control sobre la infraestructura de la que se les ofrece.
A continuación 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 representación, los rectángulos 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 física
(PIL) a menudo conocida como "granja de servidores", instalada en una
localización dada. Debido al aumento del costo de la energía consumida, el
espacio ocupado y el personal de gestión que se requiere, estas granjas de
servidores se están observando cada vez más cerca de las fuentes de
electricidad, agua, suelo y mano de obra menos costos. Estos lugares son, por su
naturaleza, ubicados geográficamente en áreas de baja demanda de servicio, y
por lo tanto la evolución de las redes de ultra alta velocidad en largas distancias
son habilitadores esenciales de estas granjas de servidores ubicados
remotamente. Además de la gestión física del hardware de computación, la PIL
12
puede permitir la consolidación 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 gestión de las fronteras en todo el parche del servidor en
términos de seguridad, cortafuegos, y la reserva de ancho de banda de acceso.
Por ejemplo, la configuración y la gestión de redes LAN virtuales se realiza a
través de la PIL.
La siguiente capa es la capa de infraestructura virtual (VIL) que aprovecha
las capacidades de virtualización 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 comunicación. En muchos
casos, la VIL será interna a una organización que ha alquilado un parche
completo de servidores físicos para ejecutar su negocio. Sin embargo, también
es concebible que los servicios VIL se encuentren en realidad bajo el control del
proveedor de la infraestructura que presenta efectivamente una abstracción del
parche de servidor virtual para sus clientes. Esto es similar a la computación en
nube, salvo que el suscriptor de un parche de servidores virtuales esperaría
acuerdos de nivel de servicio (SLAs) explícitos en términos de computación,
almacenamiento e infraestructura de red asignados y necesitaría visibilidad
suficiente para proporcionar su propia gestión del nivel requerido para el
funcionamiento de servicios múltiples o aplicaciones.
Figura 6. Modelo de Conceptual de Capas : Infraestructura Virtual e Infraestructura Física
La tercera capa en el modelo es la capa de la Coordinación de Infraestructura
Virtual (VICL) cuyo objetivo es atar los parches del servidores virtuales en
13
varias granjas de servidores físicos con el fin de crear un centro de datos
virtualizado distribuido geográficamente (DVDC). Esta capa debe definir y
gestionar las ‘tuberías’ virtuales entre distintos centros de datos virtuales. Esta
capa también sería responsable de la ubicación geográfica a través del
despliegue, la ejecución y la migración de las aplicaciones, cada vez que sea
necesario. En función de sus capacidades, VICL podría ser explotado para otros
fines, tales como la reducción de los costos de energía al distribuir la carga a
través de husos horarios y tarifas de servicios públicos, proporcionando
recuperación ante desastre o gran escala de tolerancia a fallos, e incluso
permitiendo cálculos distribuidos verdaderamente grandes.
Por último, la capa de proveedor de servicios (SPL) es responsable de la
gestión y ejecución de aplicaciones en el DVDC construidas por el VICL. El SPL
requiere de visibilidad sustancial de la configuración física, 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
ubicación, no virtualizado y enteramente en propiedad de una sola
organización; hasta uno distribuido geográficamente (entro de datos totalmente
virtualizado) donde cada capa tiene posiblemente un propietario
independiente. Este último extremo no solo proporciona una serie de ventajas
en términos de la consolidación, agilidad y flexibilidad, sino que también
plantea una serie de retos difíciles en términos de seguridad, definición de SLAs
y el cumplimiento, la eficacia y los problemas de separación de capas.
14
4 Infraestructura de Red en Centros de Datos
La creciente complejidad y sofisticación de las aplicaciones de centros de
datos exige nuevas características de las redes. Para las aplicaciones en clúster,
los servidores necesitan a menudo intercambiar mensajes de comunicación
entre procesos (IPC) para la sincronización e intercambio de datos, y estos
mensajes pueden requerir de muy baja latencia para reducir la espera de
procesos.
La comunicación directa entre servidores también 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 diseño 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 desafíos 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 más importantes en relación con el entorno del centro de
datos.
La capa Ethernet es crucial en los centros de datos principalmente porque en
una infraestructura típica se pueden encontrar más conmutadores de Nivel 2
(switches) que enrutadores (Nivel 3). Esto tiene como resultado un costo
mucho menor, en función de la latencia y la sencillez de configuración de un
conmutador de Nivel 2 en comparación con un router. Sin embargo, esto podría
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 tuviéramos que
simplemente poner en práctica todos estos mecanismos en el Nivel 2
directamente, los conmutadores se volverían tan complejos, lentos y difíciles de
configurar y administrar como los routers.
Una capacidad única introducida en la red Ethernet en el estándar IEEE
802.1q es la noción de virtual LAN o VLAN. El mecanismo de VLAN permite
15
que el tráfico se identifique con una VLAN ID de 12 bits. En un caso de
asignación estática simple, las VLAN ID son estáticamente asignadas a los
puertos del switch. Esto permite que las VLAN puedan proporcionar un fuerte
aislamiento en el tráfico que pertenece a una VLAN y no pueda ser dirigido a
los puertos que no están asignadas a esa VLAN. Existe también un esquema de
asignación dinámica que puede asignar una VLAN a un conjunto único de los
puertos en función de la dirección MAC de origen o de otros atributos del
tráfico.
Figura 7. Ubicación del Etiquetado VLAN en una trama Ethernet
Dado un conjunto extremos de Nivel 2 (por ejemplo, servidores o
enrutadores) conectados a través de una red de conmutadores, un mecanismo
de enrutamiento Nivel 2 es esencial para proporcionar una entrega de baja
latencia de tramas Ethernet sin ningún tipo de bucles o de configuración
compleja. El diseño original del Nivel 2 de enrutamiento se centró
principalmente en evitar los bucles de mediante la definición de un único árbol
de expansión 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 expansión y por lo tanto su
ancho de banda disponible se desperdicia.
Además, la estructura de árbol se traduce en una distribución de tráfico 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 tráfico, (b) Rapid STP (RSTP) que detecta rápidamente
enlaces caídos y reconfigura el árbol de expansión para reducir al mínimo
pérdida de tramas, y (c) Multiple STP (MSTP), que utiliza varios árboles
"regionales" conectados a través de un árbol de expansión superior central
(CST). Otras formas de utilizar varios árboles incluyen: (a) cada puerto del
switch actúa como la raíz del árbol de expansión para el tráfico entrante a ese
16
puerto, y (b) Tráfico de dirección de la misma fuente, entre varios árboles de
acuerdo con algunos criterios. A pesar de estos mecanismos, equilibrar el tráfico
entre los diferentes eslabones aún podría 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 también 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 tráfico (por ejemplo, almacenamiento vs comunicación entre
procesos vs cliente - servidor).
El grupo de trabajo de IEEE sobre la gestión de la congestión Ethernet,
conocido como 802.1Qau, está estudiando la forma de mejorar la notificación y
la gestión de la congestión. 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 múltiples tipos de tráfico.)
Aunque la capa IP proporciona un amplio conjunto de mecanismos de
control de calidad de servicio, añade 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 núcleo.
La adopción 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
10µs, pero esto aún no puede satisfacer las nuevas aplicaciones de minería 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 más. Una de las dificultades en la aplicación de RDMA a
través 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 través
de la cual la mayoría de las aplicaciones operan. Sin embargo, TCP fue
diseñado para un entorno de Internet abierta muy variable, y tiene numerosas
17
deficiencias desde una perspectiva de centro de datos. En particular, es bien
sabido que el logro de una buena calidad de servicio es muy difícil con TCP ya
que múltiples flujos TCP que compiten tenderán a dividir el ancho de banda
disponible igualmente, en vez de hacerlo de acuerdo a las fracciones
especificadas. Del mismo modo, el control de congestión TCP puede ser
innecesariamente pesado para los centros de datos. En particular, TCP ofrece
esquemas elaborados para hacer frente a las pérdidas de paquetes, que rara vez
se presentan en los centros de datos bien configurados. Las pérdidas de
paquetes también pueden ser altamente indeseables a altas velocidades en las
que pueden degradar sustancialmente el rendimiento de la aplicación. Las
implementaciones TCP basadas en retraso, tales como TCP-Vegas son mucho
más apropiados para los centros de datos, pero estas versiones no son muy
populares.
TCP también sufre de otros puntos débiles que se han tratado por otros
protocolos compatibles como SCTP (protocolo de transmisión de control de
stream). SCTP surgió de la necesidad de emular capacidades en el Internet en
el sistema de señalización Nº 7 (SS7). Aunque SCTP es un protocolo aún más
pesado que el TCP y por lo tanto puede ser difícil de escalar a altas velocidades,
ofrece un número de características que pueden ser útiles en los centros de
datos. Estas incluyen:
1. Multi-homing, que permite a una conexión usar rutas alternativas en caso
de fallo de ruta principal.
2. Mejor resistencia contra ataques de denegación de servicio (DoS) al
retrasar la asignación de memoria para la información de conexión y las
verificaciones de tipo reto-respuesta. En particular, SCTP no sufre del conocido
"ataque SYN" de TCP.
Figura 8. Flujo de Información del Protocolo SCTP
18
3. Mejor robustez debido al CRC de 32 bits (frente a 16 bits para TCP) y una
función 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 través del mecanismo de "fragmento", que
permite la introducción de nuevos tipos de mensajes de control.
5. La preservación de los límites de mensaje de capa superior, lo que
simplifica la implementación RDMA.
6. Más flexible entrega (ordenada o desordenada, y control sobre el número
de retransmisiones). Por ejemplo, la entrega ordenada es necesario para
RDMA.
SCTP también es compatible con el concepto de un "stream", que es un flujo
lógico dentro de una conexión 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 múltiples conexiones. Desafortunadamente, la mayoría de las
implementaciones de SCTP no optimizan esta función.
4.2 Desafíos de las Redes en Centros de Datos En esta sección, se identifican los requisitos de red impuestas por la
evolución de los centros de datos y, a continuación 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 Capítulo 3, se intenta crear la abstracción de un único centro de
datos que podrían ser distribuidos geográficamente. Si bien esto es una
abstracción útil, es crucial tomar ventaja de la estructura de 2 niveles situada
debajo: alto ancho de banda y baja latencia, comunicación casi libre de errores
dentro de un parche de servidores físicos, y mucho mayor latencia y entorno de
comunicación de baja velocidad entre los centros de datos. En particular, a
nivel de middleware, la asignación de recursos y la migración deben tener en
cuenta de forma automática para esta discrepancia. Del mismo modo, en el
nivel de transporte los protocolos deben ser de ajuste automático y capaz de
trabajar bien tanto para los caminos que se mantienen completamente dentro de
un parche de servidores y los que van a través de parches diferentes.
Dado que las comunicaciones intra e inter parches de servidores tienen
19
características muy diferentes, dan lugar a desafíos muy diferentes. Por
ejemplo, un control de flujo basado en el crédito simple es apropiada para las
comunicaciones intra parches de servidores porque ofrece pequeños tiempos de
ida y vuelta (RTT), mínima pérdida de paquetes, y un uso muy bajo de CPU.
Por otro lado, para las comunicaciones inter parches de servidores, un buen
rendimiento bajo pérdida de paquetes debido a la congestión 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 tecnologías de red de cable (cobre y/o fibra) de
permanecerán dominantes en los centros de datos, las tecnologías inalámbricas
como Wi-Fi, ultra-ancha (UWB) y transmisiones ópticas en el espacio libre están
encontrando nichos para su aplicación a medida que aumenta el ancho de
banda disponible. Por ejemplo, el ancho de banda inalámbrica disponible
puede ser adecuados para centros de datos de gama baja que ejecuten
aplicaciones de cálculo intensivo. Incluso en los centros de datos más grandes,
la tecnología inalámbrica puede resultar muy adecuada como para una red de
gestión. Las tecnologías inalámbricas tienen la importante ventaja de eliminar el
problema de gestión de cables, para permitir la adición/supresión de la
infraestructura, y proporcionar un medio de comunicación de difusión (a
diferencia de punto a punto) que puede ser explotado de manera inteligente.
Para apoyar esta diversidad en capas MAC, debería ser posible elegir el
mecanismo de control de congestión en función de las capas atravesadas. Para
un protocolo orientado a conexión, el control de la congestión puede ser
negociado durante el establecimiento de la conexión, sin embargo, en algunos
casos, los ajustes dinámicos automatizados pueden también ser necesarios.
A medida que la tecnología 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 tamaño promedio de 1.000 paquetes byte debe ser
procesado en menos de 80 ns. Con un protocolo complejo, es muy difícil 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 estarán limitados por el
20
fenómeno llamado "memoria-wall". Por lo tanto, además de la colocación
directa de los datos en las memorias caché, es necesario ir más 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 sección
transversal de ancho de banda limitado que podría convertirse en un problema
en los grandes centros de datos. Este problema puede ser abordado mediante el
uso de muchos más switches, pero de menor capacidad, en los niveles
superiores de la jerarquía en una topología CLOS o “fat-tree”. Un problema con
este enfoque es el aumento en el número 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 ubicación jerárquica 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 también explorados, en donde los conmutadores
Ethernet estándar 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 Capítulo 3 se introdujo el concepto de clúster virtual (VC), el cual
requiere de aprovisionamiento rutas de comunicación controladas mediante
QoS entre los nodos virtuales. Para permitir esto, es necesario etiquetar todas
las comunicaciones dentro de un clúster virtual de modo que sea posible
diferenciar entre varios clústeres virtuales que comparten las mismas rutas de
comunicación. Además, es necesario pensar en calidad de servicio en términos
21
de las necesidades de toda la aplicación, más 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 aplicación que se ejecuta en el clúster virtual) o basarse en los cambios
dinámicos de las necesidades de las aplicaciones. Una forma de estimar la
necesidad de ancho de banda dinámico es hacer un seguimiento del uso de
ancho de banda real durante los períodos sin congestión y luego dividir el
ancho de banda disponible en esa proporción durante los períodos de
congestión.
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 gestión de etiquetas y el ancho de banda
provisto. El proyecto de centro de datos en Ethernet del IEEE se ocupa
básicamente de aprovechar los tres bits existentes de CoS (Class of Service) en la
trama Ethernet para etiquetado y gestión de ancho de banda.
Figura 9. Bits de ‘Clase de Servicio’ en una Trama Ethernet
La expansión de este mecanismo a los clústeres virtuales en toda regla
requeriría perturbaciones importantes en el estándar Ethernet existente y
todavía requeriría un mecanismo en la capa IP para manejar grupos virtuales
que van a través 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 configuración. Estos pueden ser usados
para la configuración de caminos entre parches de servidores, pero no son útiles
22
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 fácil de implementar,
pero sólo tendrá importancia variable. Es decir, mientras que las etiquetas se
pueden utilizar para el control de la congestión de las conexiones que
pertenecen a diferentes grupos virtuales, no se repercute su aplicación en la
propia red. Algunos autores proponen un mecanismo de marcado junto con la
noción de control de ancho de banda colectiva que determina de forma
automática 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 difícil con TCP como mecanismo de control de
congestión.
En un entorno virtualizado, la comunicación entre los nodos necesita un
mecanismo para detectar automáticamente cuando dos nodos se encuentran en
la misma plataforma y por lo tanto se pueden comunicar sin la participación de
la red externa. Los recientes avances como XenLoop proporcionan un
mecanismo transparente para interceptar automáticamente los paquetes de
máquinas virtuales co-residentes y los coordinará a través de la interfaz de
memoria compartida. Un tema similar se plantea para la comunicación 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 comunicación. Proporcionar un mecanismo de comunicación de bajo
“overhead” y transparente entre VM's que se pueden migrar de forma
dinámica, así como el soporte de hardware, sigue siendo un problema difícil.
Mientras los centros de datos se mueven de entidades físicas en propiedad al
modelo DVDC discutido previamente, se hace mucho más difícil protegerlos
contra la denegación 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 protección a tasas muy
altas de transmisión de datos que pueden ser vistos en el futuro. Del mismo
modo, el apoyo a mecanismos de alta disponibilidad tales como multi-homing,
la migración de conexión, la diversidad y el control de rutas se han convertido
en algo crítico en este entorno; sin embargo, la búsqueda de soluciones
23
escalables para ellos puede ser muy difícil.
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 implementación,
configuración, ingeniería de tráfico, y mantenerlos actualizados es a menudo
una tarea muy difícil y sigue aumentando en complejidad a medida que crecen
los centros de datos, pero no ha recibido mucha atención en la literatura. La
gestión de estos dispositivos en un entorno DVDC puede ser particularmente
difícil, puesto que los propios cuadros intermedios pueden necesitar ser
virtualizados sin comprometer la seguridad, el aislamiento y las características
de rendimiento que están destinados a proporcionar.
4.3 VXLan : Superando el límite de VLans La virtualización de servidores ha generado una mayor demanda sobre la
infraestructura de la red física. Como mínimo, hay una necesidad de más
entradas de la tabla de direcciones MAC a lo largo de la red de conmutación
Ethernet debido a la potencial agregación de cientos de miles de máquinas
virtuales (VM), cada una con su propia dirección MAC.
En segundo lugar, las máquinas virtuales pueden ser agrupadas de acuerdo
a su LAN virtual (VLAN) funcional. Un centro de datos puede necesitar miles
de VLANs para dividir el tráfico de acuerdo con el grupo funcional específico al
que la máquina virtual puede pertenecer. El límite 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 tráfico en
Nivel 2 a través de todo el centro de datos o incluso entre varios centros de
datos para la asignación eficiente de recursos de computación, recursos de red y
almacenamiento. Utilizar enfoques tradicionales como Spanning Tree Protocol
(STP) para una topología sin bucles puede resultar en un gran número 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 múltiples sistemas huéspedes, cada uno con su dominio de
red aislada. Esto no resulta económico utilizando infraestructura dedicada, por
lo que los administradores de red optan por implementar una red compartida.
24
Un problema recurrente es la asignación independiente de direcciones MAC y
VLAN ID que conducen a la potencial duplicación de estas en la red física.
El último escenario es el caso en que el operador de la red prefiere utilizar IP
para la interconexión de la infraestructura física (para lograr escalabidad a
través de multitrayecto con igualdad de costo [ECMP]) y al mismo tiempo
conservar el modelo de Nivel 2 para la comunicación inter-VM.
Los escenarios descritos anteriormente conducen a la exigencia de una red
superpuesta. Esta red se utilizaría para transportar el tráfico MAC desde las
VMs individuales en un formato encapsulado sobre un "túnel" lógico.
Figura 10. Ubicación 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 máquinas virtuales en
un entorno multiusuario. Se ejecuta a través de la infraestructura de red
existente y proporciona un medio para "ampliar" la redes de Nivel 2. En
resumen, VXLAN es un esquema de superposición de Nivel 2 en una red de
Nivel 3. Cada capa de superposición o ‘overlay’ se denomina segmento
VXLAN. Sólo las máquinas virtuales en el mismo segmento VXLAN pueden
comunicarse entre sí. Cada segmento VXLAN es aislado en ámbito de
operación a través 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 máquina virtual
individual. Por lo tanto, podría haber superposición o solapamiento de
direcciones MAC a través de segmentos, pero nunca tener tráfico cruzado entre
ellos, ya que el tráfico 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 término "segmento VXLAN" se usa de
manera intercambiable con el término "red superpuesta VXLAN."
Debido a esta encapsulación, VXLAN también podría denominarse como un
esquema de tunelización para superponer las redes de Nivel 2 sobre redes de
25
Nivel 3. Los túneles son ‘stateless’, así que cada trama se encapsula según un
conjunto de reglas. El punto final del túnel (VTEP) se encuentra dentro del
hipervisor en el servidor que aloja las máquinas virtuales. Así, el VNI y el túnel
VXLAN, conjuntamente con la cabecera, son visibles únicamente a al VTEP (la
máquina virtual no lo ve). Los VTEPs también podrían encontrarse en un
switch o servidor físico y podrían ser implementados en software o hardware.
A continuación se examinan escenarios típicos de flujo de tráfico en un
entorno VXLAN utilizando un tipo de esquema de control – aprendizaje del
plano de datos. En estos casos, la asociación de MAC de las VMs a las IP de los
VTEP es descubierta a través de aprendizaje del origen. Se utiliza Multicast
para llevar tramas con destino desconocido, así como tramas de broadcast y
multicast.
En adición a un plano de control basado en el aprendizaje, hay otros
esquemas posibles para la distribución de las asociaciones de la IP del VTEP a
las MAC de VMs. Estas opciones podrían incluir una búsqueda en un
directorio central realizada por los VTEPs individuales; o la distribución directa
de esta información de mapeo hacia los VTEPs por el directorio central. Estas
opciones son a veces caracterizadas como modelos de ‘push’ y ‘pull’.
A continuación 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 más 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 más interna) :
1. Cabecera VXLAN : Este es un campo de 8 bytes que contiene los siguientes
26
- Banderas (8 bits) : Donde la bandera I debe establecerse en 1 para un ID
de red VXLAN válido. 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 están comunicándose. 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 número 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 entropía para
balanceo de carga/ECMP de la máquina virtual para el tráfico entre VMs a
través de la VXLAN.
El campo checksum UDP debe transmitirse como cero. Cuando se recibe un
paquete con una suma de comprobación o ‘checksum’ igual a cero, éste deberá
ser aceptado para ser desencapsulado. Opcionalmente, si el extremo
encapsulado incluye una suma de comprobación 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 comprobación no
nula puede optar para verificar el valor de suma de comprobación. Si opta por
realizar la verificación y ésta falla, el paquete debe rechazarse. Si el destino
decide no realizar la verificación o la realiza con éxito, el paquete deberá ser
aceptada para ser desencapsulado.
27
3. Encabezado IP Exterior : Contiene la dirección IP de origien, indicando la
dirección IP del VTEP sobre el que se comunican las VMs (tal como lo
representan la dirección de MAC interna). La dirección IP de destino puede ser
unicast o multicast. Cuando es una dirección IP unicast, contiene la dirección IP
del VTEP que conecta a las VMs que están comunicándose.
Tradicionalmente, las redes de Nivel 2 sólo puede ser atacadas desde
"dentro" por los extremos implicados, ya sea por el acceso inadecuado a una
LAN, inspeccionando el tráfico, o mediante la inyección de paquetes
falsificados para suplantar otra dirección MAC, o causando inundaciones del
tipo DoS. Un mecanismo de MAC-sobre-IP para la entrega de tráfico 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 suscripción a uno o
más 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 tráfico espúreo.
Los ataques de Nivel tradicionales realizados por puntos finales falsos
pueden ser mitigados mediante la limitación del ámbito de la gestión y
administración de quien despliega y gestiona VMs en un entorno VXLAN.
Además, las medidas administrativas ya disponibles pueden ser aumentadas
por esquemas como 802.1X para el control de admisión de los puntos finales
individuales. También, el uso de encapsulación basada en UDP de la VXLAN
permite la explotación de la funcionalidad de Listas de Control de Acceso
(ACL) basada en 5 tuplas de los conmutadores o switches.
El tráfico de túnel a través de la red IP se puede asegurar con mecanismos de
seguridad tradicionales, como IPsec para la autenticación y, opcionalmente el
cifrado del tráfico VXLAN. Esto, por supuesto, deben complementarse con una
infraestructura de autenticación 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 están
autorizados en la LAN, se recomienda que las VLAN sean designadas para el
tráfico VXLAN, y los servidores/VTEPs envien tráfico VXLAN sobre esta
VLAN para proporcionar una medida de seguridad.
Además, VXLAN requiere de una asignación adecuada de VNIs y
28
pertenencia de VM en las redes superpuestas. Se espera que esta asignación se
haga y se notifique a la entidad de gestión en el VTEP y las pasarelas utilizando
los métodos existentes de seguridad.
29
5 Almacenamiento en los Centros de Datos
A pesar del enorme crecimiento en la capacidad de almacenamiento en la
última década, el tsunami de datos no muestra señales 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 expansión mundial
conectividad; el crecimiento del almacenamiento continúa acelerándose.
De acuerdo con estimaciones del IDC, el volumen de datos sigue
aumentando 50-70% por año. Estas tendencias hacen que la gestión de
almacenamiento en los centros de datos sea extremadamente desafiante. En
este Capítulo ofrecemos una visión general de las tecnologías emergentes de
almacenamiento y las necesidades de las aplicaciones; para luego discutir los
principales desafíos.
5.1 Conceptos básicos de almacenamiento Hasta hace poco, la mayor parte del almacenamiento utilizaba medios
magnéticos de rotación, y las arquitecturas de almacenamiento se desarrollaban
alrededor de esta tecnología.
El almacenamiento en centros de datos puede tomar una las tres formas
siguientes, o una combinación 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 también proporciona acceso al
almacenamiento que residen en una red, pero accesible a través de una interfaz
de nivel superior, tales como archivos u objetos.
La tecnología 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 están volviendo
cada vez más difíciles de superar a medida que avanzamos en los diseños más
rápidos y más densos. En particular, el movimiento mecánico implica que los
discos seguirán siendo significativamente más rápidos 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
30
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 energía que otros componentes de un servidor (por
ejemplo, aproximadamente 12 W frente a 150 W para el subsistema de
procesador), el gran número de dispositivos de almacenamiento se traduce en
que un 20 - 30 % de la energía del centro de datos podría 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 pequeñas fracciones de patrones de
acceso aleatorio pueden degradar seriamente el rendimiento. Sin embargo, un
conjunto de 15 unidades de estado sólido o híbrido podría superar fácilmente
este límite, lo que implica la necesidad de interfaces más rápidas.
La interfaz SCSI de conexión 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 también están siendo reemplazada por la versión de serie llamada
SATA.
Figura 12. Características de diversas Interfaces de Almacenamiento
Aunque el almacenamiento de conexión directa (DAS) en cada servidor
puede proporcionar un acceso más rápido, tiene numerosas limitaciones en
cuanto al tamaño y la flexibilidad. En consecuencia, la capacidad de
almacenamiento dentro del servidor es generalmente pequeño y reservado para
los datos locales, tales como la imagen de arranque y el espacio de intercambio.
31
El almacenamiento compartido generalmente se aprovisiona por separado en
una "torre de almacenamiento" y se accede a través 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 gestión de
almacenamiento (por ejemplo, los sistemas de base de datos). Tanto NAS y
SAN (se discute a continuación) encuentran un límite 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 tecnología de red
preferida para su implementación. Aunque FC está diseñado específicamente
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 través de la conexión principal
Ethernet (la interfaz de hardware podría 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 fácil 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 aparición de Ethernet 10 GB/s de bajo coste
también ha hecho que iSCSI sea mucho más atractivo.
Muchas aplicaciones que utilizan almacenamiento de acceso de bajo nivel
(por ejemplo, sistemas de gestión de bases de datos) están diseñados para el
almacenamiento FC. Por lo tanto, a pesar de una eventual tendencia a un iSCSI
mucho más barato o soluciones basadas en Ethernet similares, las interfaces FC
serán utilizadas por bastante tiempo. Varios protocolos estándar han sido
diseñados para la interconexión de FC y TCP/IP. El protocolo FCIP encapsula
FC paquete en los paquetes TCP para la transmisión a través 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 transmisión directa de la carga
útil del paquete FC través de una red TCP/IP intermedia.
32
En general, un volumen de almacenamiento puede propagarse a través de
múltiples dispositivos de almacenamiento físicos o lógicos, y una visión
consistente requiere de "virtualización del almacenamiento". La virtualización
del almacenamiento puede ser basado en host, basada en la red o en dispositivo
de almacenamiento. Una solución basada en host ampliamente desplegada es
Logical Volume Manager (LVM) en el sistema operativo huésped, el cual
maneja volúmenes de almacenamiento repartidos en varios dispositivos bajo su
control. La virtualización basada en red realiza la misma tarea utilizando
algunos "aparatos" directamente conectados a la red de servidores. En una
versión más sofisticada de este enfoque las rutas de datos y de meta-datos
pueden ir a través de redes separadas. En aún otra variación, la funcionalidad
de virtualización 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 número de saltos de la red.
Por último, el dispositivo de almacenamiento en sí puede proporcionar esta
funcionalidad. Con la mayoría de estas soluciones, la virtualización se extiende
sólo al alcance del agente de control (host OS, switch, etc) y la interoperabilidad
se hace difícil ya que los diferentes sistemas operativos, aplicaciones y
dispositivos de almacenamiento pueden implementar la virtualización de
forma diferente.
La unificación de múltiples subsistemas de almacenamiento virtualizados
requiere una entidad de nivel superior para coordinar el acceso a través de
estos subsistemas. Esta unificación es requerida cada vez más debido a las
limitaciones en espacio de almacenamiento tradicional NAS / SAN. Un ejemplo
muy conocido de esta coordinación es el sistema de archivos en clúster (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 distribución a través del grupo de archivos y objetos, y
permitiendo el acceso transparente a los archivos y objetos almacenados en
cualquier lugar a través de los nodos del clúster. Funciones de almacenamiento
nominales como striping y mirroring deben ser proporcionados por el CFS en el
clúster de manera transparente. CFS también tiene que ofrecer resiliencia frente
a los dispositivos de almacenamiento a través de grupos que pueden
experimentar fallas. Algunos ejemplos de CFS, diseñados 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).
33
5.2 Almacenamiento en discos de estado sólido e híbridos La mejora continua en el coste y el rendimiento de almacenamiento basado
en memoria flash ha hecho de los discos de estado sólido (SSD) una tecnología
viable en los centros de datos. Por otra parte, existen otras tecnologías RAM
(NVRAM) que pueden alterar significativamente el paisaje de almacenamiento
en el futuro cercano. Algunas de las tecnologías más prominentes incluyen
NVRAM RAM magnética (MRAM), la memoria de cambio de fase (PCM o
PRAM) y la RAM Ferro-eléctrica (FeRAM). Las tecnologías NVRAM ofrecen
varias ventajas sobre los medios magnéticos rotativos:. Latencias de acceso
inferiores y más previsibles para las solicitudes al azar, factores de forma más
pequeños, menor consumo de energía, la falta de ruido y mayor robustez a las
vibraciones y la temperatura. Puesto que la memoria flash NAND es el más
maduro y popular de ellos en este momento, vamos a utilizar esta tecnología
como representativa para conducir la discusión.
Figura 13. Memoria de Núcleo Magnético (a) y Ferro-Eléctrica (b)
Comenzamos con algunas características de almacenamiento basado en flash.
Los dispositivos Flash requieren una operación de borrado antes de que los
datos se pueden escribir, y éste borra sólo puede realizarse en unidades de
bloques. Un bloque consta de 64 o 128 páginas. Una página es la granularidad
de lecturas y escrituras individuales, y es típicamente de 2 KB de tamaño. Una
operación de borrado no sólo es muy lenta (alrededor de 2 ms para bloque 128
K), sino que también da como resultado una ligera degradación del flash,
limitando de este modo el tiempo de vida útil de un bloque. Cada bloque tiene
típicamente una vida de aproximadamente 100 K operaciones de borrado K.
Existen técnicas de nivelación de desgaste que distribuyen la ubicación física
del bloque de tal manera que los borrados se extienden uniformemente a través
de toda la memoria flash.
Cada página del flash puede estar en uno de tres estados diferentes: (i)
válida, (ii) no válido y (iii) libre / borrado. Cuando ningún dato se ha escrito en
una página, se encuentra en estado libre o borrado. Una escritura puede hacerse
34
sólo a una página libre, cambiando su estado a válido. Un recolector de basura
(GC) se ejecuta periódicamente e identifica los bloques que sólo contienen
páginas no válidas y las borra. Durante los períodos 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 más de uno. MLC proporciona una mayor densidad y
por lo tanto menor coste global, sin embargo, esto se produce a expensas de una
velocidad más 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 más altas). Por lo tanto, las
unidades de estado sólido (SSD) utilizan invariablemente SLC, siendo MLC
más común en las aplicaciones de consumo tales como unidades flash.
Con el fin de mantener la compatibilidad con los discos duros, los SSD están
diseñados para utilizar interfaces de E/S estándar tales como buses de SCSI o
SATA. Un procesador integrado implementa la llamada Capa Traducción 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 traducción de direcciones lógicas a
direcciones físicas para permitir la nivelación del desgaste, (ii) actualizaciones
fuera de rango y recolección de basura, y (iii) las políticas de nivelación de
desgaste. La calidad de la ejecución 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 nivelación de desgaste a veces puede hacer a los SSDs
más lentos que los discos duros. Para accesos secuenciales, los discos duros
pueden superar fácilmente los SSD. Sin embargo, los SSD tienen un gran
potencial para un rendimiento más alto y más 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 jerarquía de almacenamiento entre la memoria
35
principal y el disco duro de almacenamiento secundario. Sin embargo, muchos
otros problemas en la integración de los SSD's y discos duros para un
rendimiento más rápido y más consistente aún no se han resuelto.
Figura 14. Controlador de Memoria Flash
5.3 Desafíos en el almacenamiento Aunque la virtualización y agrupación proporcionan mecanismos para
manejar grandes cantidades de almacenamiento, el cada vez mayor volumen de
datos almacenados seguirá planteando problemas de escalabilidad en múltiples
niveles. La gestión de un gran número de dispositivos de almacenamiento (que
se puede dividir en varios grupos) no plantean importantes desafíos en
términos de rendimiento y disponibilidad. Otra cuestión se refiere a la gestión
eficiente de un gran número de objetos (como archivos) que se espera que un
sistema de almacenamiento de gran tamaño pueda albergar.
Los tamaños de los objetos mismos podrían variar en un amplio rango. En
particular, la distribución de tamaño de archivo Zipf típica implica que (a) los
centros de datos tienen un gran número de archivos pequeños y (b) los archivos
en el extremo más grande podrían ser muy grandes en tamaño y pueden estar
distribuidos en varios dispositivos o incluso grupos. Hacer un seguimiento de
un gran número de archivos implica desafíos en la forma de representar de
manera eficaz, gestionar y manipular los metadatos de archivos. Sin embargo,
no podemos limitarnos a diseñar mecanismos que funcionan bien sólo para
sistemas de archivos de gran tamaño. El número de los objetos administrados
36
por diversas instancias del sistema de archivos tiene en sí misma la
probabilidad de seguir distribuciones similares a Zipf. En consecuencia, la
gestión de meta-datos debe ser diseñada para tomar ventaja de los pequeños
tamaños del sistema de archivos siempre que sea el caso. Problemas similares
aplican con respecto a tamaño de los archivos también. El diseño debe ser capaz
de proporcionar asignación, acceso y actualizaciones eficientes no sólo para
archivos de gran tamaño que pueden acumular petabytes, sino también a los
pequeños archivos que son sólo unos pocos cientos de bytes.
Muchas aplicaciones emergentes implican trabajar con grandes cantidades de
datos, tanto de manera permanente como transitoria (o temporal). Una
compensación adaptativa entre cómputo y almacenamiento puede ser útil en el
trabajo con dichos datos. Por ejemplo, los datos que se acceden con poca
frecuencia podrían ser comprimidos o ser regenerados cada vez mediante la
ejecución de transformación apropiada, simulación o programa de filtrado. La
cuantificación de la compensación o compromiso (trade-off) entre computación
y almacenamiento exige abordar cuestiones tales como (a) de almacenamiento
de energía vs CPU consumido, (b) impacto en el rendimiento de las técnicas de
ahorro de almacenamiento, y (c) la colocación de datos y la migración a través
de la jerarquía de almacenamiento.
Debido a sus muy diferentes características operativas, los dispositivos de
almacenamiento (discos duros, tecnologías de memoria principal, y SSD)
requieren nuevas estrategias de modelado. En particular, las actualizaciones de
datos deslocalizados, recolección de basura y nivelación de desgaste perturban
las características de acceso del tráfico entrante y deben ser abordados en el
modelado. También, como un SSD obtiene cada vez más desgaste con el
tiempo, sus operaciones de borrado se ralentizan considerablemente, lo que
requiere más reintentos y mala reasignación de bloques, reduciendo de este
modo el rendimiento efectivo del dispositivo. La GC y algoritmos de nivelación
de desgaste también afectan el consumo de energía y tiempo de vida en formas
complejas que no son triviales para modelo.
Una cuestión relacionada con SSD, y más generalmente con el
almacenamiento basado en NVRAM es volver a examinar la distinción
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
37
de finalización E/S es muy grande en comparación 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 sólido muy rápido, tal distinción
podría dejar de presentarse y un mecanismo de cambio de contexto adaptativo
puede ser necesario. Además, un almacenamiento de acceso rápido 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 más 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 técnicas de virtualización de almacenamiento discutidas anteriormente
se dirigen principalmente hacia la agregación de un gran número de
dispositivos de almacenamiento y la creación 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 partición de
almacenamiento con el aislamiento y la protección adecuados de otros CDA, y
sin embargo, debería ser posible desplazar los límites de la partición según sea
necesario. Además, debería ser posible para gestionar el almacenamiento en
cada VCC a un nivel bastante bajo de modo, que cada CDA puede configurar el
almacenamiento en función de sus necesidades. Proporcionar tal capacidad de
"desagregación", además de la capacidad de adición usual utilizada, es
actualmente un problema abierto que no esté contemplado en las capacidades
de almacenamiento ofrecidas por las nubes actuales.
38
6 Gestión de la configuración en los centros de datos
La gestión 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 más detalle en el Capítulo 6.1.
Gestión generalmente implica dos partes distintas: (a) las operaciones y (b) el
control. En términos generales, las operaciones se refieren a la instalación,
configuración, actualización y otras actividades de tiempo con gruesa
granularidad; mientras que el control se refiere a la gestión 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 gestión de placa base (BMC). Sin embargo, a medida que
avanzamos a la gestión del modelo más general DVDC discutido
anteriormente, esta distinción entre las operaciones y el control o la separación
entre el fuera de banda y las actividades dentro de banda se vuelve menos
clara. Por ejemplo, la configuración o la reconfiguración de una máquina
virtual podría ser considerada parte de las actividades de control. Del mismo
modo, la información obtenida de ambos OOB y en banda debe combinarse
para una configuración y control efectivo.
La gestión de centros de datos modernos implica un gran número de
cuestiones que se hacen más difíciles a medida que el número de objetos
administrados aumenta. A continuación se discuten estos temas y los
problemas de escalabilidad correspondientes.
6.1 Gestión del ciclo de vida Puede ser tentador pensar en centros de datos y servicios de TI como algo
estático, donde las instalaciones se instalan y luego se usan por un largo tiempo
antes de ser retirado. En realidad, la mayoría de las instalaciones están sujetas a
constante cambio : nuevos activos se instalan, y los existentes son actualizados,
reconfigurados, reutilizados, movidos a otra ubicación geográfica, o
reemplazados. Por consiguiente, es importante para automatizar estas tareas en
la medida de lo posible, de modo que las actividades de gestión se puedan
39
realizar de forma rentable (por ejemplo, con un mínimo de tiempo
administrador de TI), rápidamente, de forma segura, y con mínima exposición a
errores humanos. A continuación, se elabora sobre los desafíos de la gestión del
ciclo de vida automatizado.
Considere una situación en la que un nuevo servidor modular llega a una
instalación y es conectado a alguna ranura vacía en un rack o un chasis. Con el
fin de añadir lógicamente este servidor a la instalación, se requieren las
siguientes tareas:
1. Descubrimiento : Este paso implica el descubrimiento de la configuración
HW / SW de cada dispositivo y el servidor en su conjunto para que pueda ser
desplegado correctamente. La información producida por el descubrimiento
necesita ser almacenada en una forma estándar, de modo que se pueda utilizar
para los pasos de cualificación y aprovisionamiento que se discuten a
continuación.
2. Cualificación : Un nuevo servidor bien podría acoger HW / SW malicioso
y no debería 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 conexión, de modo que
no sea capaz de enviar paquetes a destinos restringidos. El control para ello
implica al menos 3 aspectos: (a) autenticación (tal vez basada en un certificado
almacenado en la memoria a prueba de manipulaciones [TPM] del servidor), (b)
revisión constante para la detección de malware, y (c) el cumplimiento de los
controles que aseguren que se ajusta a las políticas de TI que desee.
3. Aprovisionamiento : Este paso prepara el servidor para la instalación e
incluye una variedad de tareas, tales como particionamiento, configuración de
HW, puesta a punto, y la carga de programas del sistema base. Es probable que
el particionamiento y configuración dependa de los parches de servidor a los
cuales el nuevo activo será añadido.
4. Prestación de Servicios : Este paso asignará las particiones del servidor (o
incluso las máquinas virtuales que se ejecutan en ellas) a los centros de datos
virtuales adecuados, y las aprovisionará con el software de aplicación necesario,
acceso a la red/almacenamiento, etc.; para que puedan comenzar a prestar los
servicios previstos.
5. Supervisión y ajuste : Se refiere a la vigilancia constante de los parámetros
40
vitales del servidor y la adopción de medidas adecuadas. Los datos de
vigilancia de diversos elementos HW y SW se implican típicamente el filtrado,
el almacenamiento y la fusión con el fin de detectar y resolver problemas de
rendimiento, minimizar el consumo de energía, determinar los ataques de
seguridad, etc.
6. Corrección : Se refiere a las actividades relacionadas con la detección y
diagnóstico de fallos, la seguridad relacionada con la cuarentena, reparación,
actualización y reemplazo. Algún tipo de correción 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á automáticamente cuando un nuevo servidor se conecta.
El aprovisionamiento se inicia con el BMC encendiendo el servidor principal y
comunicándose con su firmware para arrancar el proceso de descubrimiento y
cualificación. Muchas de las otras tareas se pueden hacer en o fuera de banda, o
mediante una combinación de ambas.
6.2 Marcos operacionales de gestión Hay dos requisitos fundamentales que permiten la detección y configuración
automática : (a) La disponibilidad de la información de configuración en un
formato estandarizado en cada dispositivo y en los niveles superiores, y (b) un
marco estandarizado para recuperar y procesar esta información. El modelo de
información común (CIM) fue desarrollado por el grupo de trabajo de
administración distribuida (DMTF) para describir entidades informáticas y de
negocios, y ha sido adoptado ampliamente. CIM es un lenguaje jerárquico y
orientado a objetos de información de gestión basado en UML (Unified
Modeling Language) para la definición 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-relación y permite
conceptos de modelado orientados a objetos tales como clases anidadas, de
instancias, herencia, y agregación para permitir una descripción compacta de
los sistemas complejos en términos de sus componentes. Por ejemplo, se espera
que un modelo de CIM de un NIC de Ethernet pueda proporcionar no sólo la
estructura física de la tarjeta NIC, sino también los parámetros/capacidades
41
que se necesitan para el uso y la configuración de la tarjeta de red, velocidades
PHY disponibles o capacidad de comprobación CRC en HW. El modelo CIM
también proporciona su configuración (por ejemplo, la velocidad PHY actual y
si HW CRC está activada) y los métodos para cambiar los valores.
DMTF ha desarrollado la especificación de gestión empresarial basada en
Web (WBEM) que proporciona mecanismos para el intercambio de información
CIM de manera interoperable y eficiente. Los componentes de WBEM incluyen
la representación de la información CIM utilizando XML, las operaciones de la
CIM a través de HTTP, la gestión de los servicios web basados en WSMAN, el
lenguaje de consulta CIM, interfaz de lenguaje de comandos (CLI), y el
protocolo de ubicación de servicios CIM. Una popular implementación de
código 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 carácter de texto sin formato, las operaciones basadas en SOAP son fáciles
de depurar, pero puede ser muy pesado en términos de sobrecarga (overhead).
Los modelos CIM representan sistemas y sus parámetros sobre todo a nivel
estructural (la mayor parte de la semántica de los parámetros y la inteligencia
para configurar adecuadamente se encuentra fuera del ámbito de la CIM). Por
ejemplo, la CIM no está diseñada para especificar las relaciones complejas entre
los valores de los parámetros de varias entidades o las condiciones en que los
parámetros deben establecerse de una manera particular. Tradicionalmente,
esta inteligencia se encuentra en el código de gestión. El consorcio World Wide
Web (W3C) ha estandarizado recientemente el lenguaje de modelado de
servicios (SML) para llenar este vacío. 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
gestión de los recursos basada en las limitaciones declaradas. Sin embargo, la
especificación y el procesamiento de las restricciones complejas utilizando un
lenguaje declarativo como SML sigue siendo todo un reto.
6.3 Almacenamiento de datos de gestión El repositorio de CIM de un activo de centro de datos puede ser considerado
como una base de datos de configuración local que se puede consultar y
42
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 práctico, incluso con un pequeño número de
servidores, por dos razones: (a) repositorios CIM suelen almacenar valores de
los parámetros detallados de dispositivos individuales en lugar de atributos de
nivel superior (por ejemplo, la capacidad del servidor) que se requieren para la
administración dinámica 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
gestión viable requiere invariablemente alguna base de datos de nivel superior
que contenga no sólo porciones de la CIM del repositorio, sino también algunos
atributos derivados que se pueden utilizar más directamente en la toma de
decisiones de aprovisionamiento. Esta base de datos se conoce a menudo como
la base de datos de gestión de configuración (CMDB). De hecho, una CMDB no
depende enteramente de repositorios CIM, sino que también 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 práctica, los proveedores de software de gestión ofrecen una variedad
de productos dirigidos hacia la gestión de aspectos específicos. Por ejemplo,
una serie de paquetes están disponibles para el aprovisionamiento de equipos,
la supervisión del rendimiento, gestión de aplicaciones, migración, etc. En
adelante los llamamos paquetes de gestión externos (EMP). Muchos EMP
utilizan repositorios de datos privados por conveniencia, que pueden no ser
43
compatibles con los demás. Los datos de algunos de los planes de gestión (por
lo general los del mismo proveedor) pueden consolidarse en una sola CMDB,
pero esto aún deja el problema de administrar varias CMDB. El resultado es
una serie de repositorios con superposición o solapamiento de información,
pero incompatibles entre sí. El enfoque alternativo de un único sistema de
gestión integral de un solo proveedor también es indeseable debido a la falta de
flexibilidad.
En el pasado, las bases de datos de configuración (CIM-DB, paquete de DB o
CMDB) tuvieron tendencia a ser más bien estáticaa. De hecho las bases de datos
CIM-DB, al estar basadas en firmware y ser difícil de modificar, aún contienen
principalmente información que puede ser modificada de vez en cuando a
través de la BIOS, EFI (Interfaz de firmware prolongado) u otro programa de
control de pre-arranque. Un ejemplo de una función utilizada con poca
frecuencia es la activación /y desactivación del ‘HW threading’. Por otro lado,
una gestión ágil requiere el acceso a una gran cantidad de información
dinámica, tal como consumo de corriente de alimentación o la utilización del
ancho de banda disponible. En un entorno virtualizado, incluso los parámetros
de configuración, como la cantidad de memoria instalada y el ancho de banda
de NIC virtuales se convierten dinámicamente en parámetros modificables. Este
dinamismo trae una serie de problemas y las soluciones son cada vez más
difíciles de escalar a grandes centros de datos.
Mantener la información 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 gestión limpia,
descentralizada y fácilmente paralelizable. En el entorno virtualizado, los
parámetros de todas las máquinas virtuales que se ejecutan en la máquina física
también se mantienen mejor a nivel local. Sin embargo, las decisiones acerca de
dónde una nueva máquina virtual debe asignarse requerirían al menos parte de
la información disponible en un nivel superior.
La duplicación de datos a través de múltiples repositorios inmediatamente
trae a cuestión el mantenimiento de la consistencia y fuerza a una consideración
cuidadosa de cual información debe mantenerse, dónde y en qué forma. En un
extremo, sólo los datos estáticos (o rara vez cambiados) se conservan en el nivel
más alto y todos los datos dinámicos se obtienen de repositorio de activos,
según sea necesario. Este enfoque se convierte rápidamente en poco escalable a
44
medida que aumenta la dinámica de datos, en particular con respecto a la
información residente en el firmware. En el otro extremo, el mantenimiento de
datos dinámicos principalmente en bases de datos externas no sólo es imposible
de escalar sino que también introduce dependencias indeseables. Por ejemplo,
la imposibilidad de acceder a la base de datos externa podría dañar la
configuración de activos y causar accidentes.
Claramente, se desea un enfoque intermedio, pero no existe un marco teórico
para guiar qué información debe ir a dónde. La idea general sería la de
almacenar la información directamente más útil, pero a la vez más abstracta en
los niveles superiores; sin embargo, es muy difícil la formalización de dicha
noción. Como un ejemplo, la CMDB puede almacenar la capacidad de
computación de servidor, el cual, a su vez, depende de los parámetros de nivel
inferior, tales como el número de núcleos habilitados o la velocidad de la
memoria. En este caso, si se realiza una actualización de los parámetros 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 relación entre los datos extraídos y los datos de nivel inferior no es explícita
(por ejemplo, oculta en el código), se presenta un problema tanto con la
consistencia (falso negativo) y la actualización innecesaria (falso positivo) en las
actualizaciones.
Para habilitar la gestión integrada de un sistema complejo, a menudo es
necesario interrelacionar la información de múltiples bases de datos. Por
ejemplo, un paquete de aprovisionamiento puede mantener la información
detallada de uso de recursos, pero sólo un resumen de la información relativa a
los fallos. En contraste, un paquete que administre el reemplazo de los activos
o su actualización puede hacer justo lo contrario. Combinar la información de
estas dos bases de datos puede ser muy difícil debido a las diferencias en el
nivel de detalle y la semántica precisa de datos. Por otra parte, el filtrado y la
abstracción empleada en los datos entrantes antes de proceder a su guardado
puede ser oculto en el código, en lugar de especificarse claramente o
formalmente.
Hay dos enfoques para la coordinación de múltiples 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 interactúa. Una posibilidad
es dejar que el más alto nivel de la propia entidad sea una CMDB que mantiene
45
una versión coherente de todos los datos pertinentes abstraídos de bases de
datos de nivel inferior. Este es un reto no sólo en términos de crear una visión
unificada de los datos, pero también puede ser infranqueable debido a la
centralización de todos los datos en una CMDB.
Un método 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 más
alto nivel que pueden ser más directamente útiles en la toma de decisiones. Los
métodos para relacionar objetos derivados de los parámetros objeto de base son
necesariamente una parte de esta descripción. GRD también mantiene otras dos
cosas : (a) Las políticas para decidir qué EMP invocar y los parámetros que se
pasan a la misma, y (b) los ‘Triggers’ que definen la funcionalidad de gestión
que se activará bien sea a través 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
sólo lectura, pero no están diseñados para manejar datos altamente dinámicos.
En el contexto de nuestra Capa 4 del modelo DVDC discutido en el Capítulo
3, se requiere la administración de configuración en las cuatro capas. Por
ejemplo, el PIL debe administrar una granja de servidores completa y dar
apoyo a la creación 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 abstracción y la protección a través de esta jerarquía,
y hacerlo de una forma escalable plantea retos importantes de administración.
6.4 Desafíos en la Provisión de Servicios En un gran ambiente virtualizado heterogéneo, el aprovisionamiento de una
aplicación o un servicio puede ser un problema complejo. En general, un nuevo
servicio tiene que usar varios servidores, y la identificación de los servidores
46
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 aplicación trabajará. Para
aplicaciones en clúster, existe también un cuarto elemento que se relaciona con
el ancho de banda de la comunicación entre servidores y la latencia de ésta.
Hay por lo menos tres problemas a resolver en el cumplimiento de estas
tareas: (a) la traducción de las características de carga de trabajo de aplicación
en las capacidades requeridas, (b) estimación de la capacidad disponible de
servidores y la red, y (c) diseño 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 aún más para los DVDC ejecutando una
amplia variedad de cargas de trabajo. Por otra parte, la noción de capacidades
"disponibles" y "necesarias" añade 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
noción de ancho de banda equivalente se utiliza con frecuencia en el contexto
de la creación 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 estimación precisa puede
incluso no ser muy valiosa. Una forma extrema es la selección de los servidores
basados en un mínimo de información sobre la utilización de los diversos
recursos y características de carga de trabajo brutos conocidos (por ejemplo,
CPU requerido versus IO requerido).
En este caso, el problema de la asignación de capacidad adecuada se maneja
a través de rendimiento impulsado por el cambio del tamaño de una VM
dinámica o la migración de ésta. Una estimación más precisa de la capacidad
disponible se puede hacer mediante el BMC o controlador de nivel más alto y
las capacidades requeridas a través del modelado de la carga de trabajo.
Obviamente, hay un equilibrio entre la precisión de la estimación, la estabilidad
de carga de trabajo y la frecuencia de la migración, pero esto no es fácil de
caracterizar. Técnicas de aprendizaje de la máquina, pueden ser útiles en este
sentido.
El reaprovisionamiento dinámico de un servicio o una aplicación pueden ser
provocados por una de tres consideraciones: (a) sobredemanda de recursos en
47
uno o más nodos (incluido el ancho de banda de comunicación), (b) las
consideraciones de optimización (por ejemplo, mover la aplicación hacia un
servidor con poca carga de manera que se obtengan mejores estados de bajo
consumo), o (c) ocurrencia de eventos específicos, 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 opción incorrecta de
servidores a los que se mueve la carga de trabajo. En la mayoría de los casos, es
difícil hacer que estas soluciones sea eficientes, debido a la complejidad del
entorno. Algunos autores discuten el uso de técnicas de aprendizaje automático,
por ejemplo, para la gestión coordinada de múltiples recursos en
multiprocesadores. Técnicas similares pueden ser útiles en contextos provisión
dinámica más genera. En el caso de (c), el aspecto más importante es reanudar
rápidamente el servicio en vez de hacer la elección óptima de un nuevo
servidor. Por ejemplo, el servicio puede ser trasladado primero a otro servidor
en el mismo chasis / bastidor para reducir al mínimo la latencia de la migración
de la VM.
6.5 Desafíos en la Gestión de Procesos La discusión en el Capítulo 6.3 se centró en la jerarquía de gestión de base de
datos y los problemas causados por múltiples bases de datos. Esta discusión
asume implícitamente que los paquetes de gestión externos (EMP) pueden
manejar de forma transparente todos los activos del centro de datos. Los
propios datos de activos podrían estar contenidos en una base de datos única o
dividirse solamente los niveles más altos (por ejemplo, base de datos por
emplazamiento físico). Sin embargo, la funcionalidad de administración en sí
requiere una estructura más descentralizada. Por ejemplo, la arquitectura del
centro de datos obliga a una jerarquía de gestión de la participación a nivel de
servidor, chasis / rack y nivel de parches del servidor. De hecho, una gestión
integral implica múltiples dominios y una jerarquía dentro de cada dominio. En
un centro de datos virtualizado, hay por lo menos cuatro dominios distintos de
interés, cada uno con una jerarquía de gestión. A continuación se describen
brevemente estos dominios y sus potenciales niveles :
1. Los activos físicos: Se refiere a las agrupaciones físicas de activos y
diversos atributos de cada grupo físico (por ejemplo, las jerarquías del consumo
de corriente y la potencia máxima permitida, el número de servidores
48
infrautilizados, etc.). El nivel superior de esta jerarquía es relevante sólo si el
centro de datos se extiende a través de múltiples ubicaciones físicas.
2. Activos virtuales: Se refiere a máquinas virtuales y sus agrupaciones en
términos de jerarquías por clúster de aplicaciones, el centro de datos virtual
(que se define en un conjunto de servidores), y todo el DVDC. Se requiere esta
jerarquía para aprovisionar recursos para aplicaciones y centros de datos
virtuales.
3. Infraestructura de red: La gestión de la infraestructura de red trata del
plano de gestión de switches y routers. Esta jerarquía refleja la estructura de la
red física. La gestión de la red a través de servidores físicos 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 propósito principal de la estructura jerárquica es simplificar la gestión. La
jerarquía requiere dos funciones importantes: (a) la descomposición de una
solicitud de nivel superior en sub-peticiones que pueden delegarse a los niveles
más bajos, y (b) la propagación de los resultados y las excepciones al mayor
nivel consolidado. Por ejemplo, en el aprovisionamiento de una aplicación que
requiere muchos servidores, podemos elegir el conjunto de bastidores que serán
sede de la aplicación, y dejar la tarea de elegir los servidores reales en el
bastidor al gestor de bastidores. Esto permitiría algoritmos que se utilizarían
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 excepción en el nivel superior. Tal mecanismo se proporciona
para toda una serie continua de políticas de interacción entre nivel: en un
extremo, el nivel más alto puede seleccionar las siguientes entidades de nivel
casi al azar y dependerá del mecanismo de excepción de correctitud, y por el
otro la delegación se gestiona cuidadosamente a modo que esta excepción se
produzca raramente.
Mientras que los retos de la negociación, la delegación y retroalimentación
surgen de cualquier jerarquía, estos se hacen aún más complejos por la
presencia de múltiples bases de datos incompatibles. Además, muchas
actividades requieren la cooperación entre los distintos ámbitos : por ejemplo, la
provisión de una aplicación en clúster requiere el establecimiento de un nuevo
49
grupo de máquinas virtuales, sin embargo, la asignación de este grupo a la
infraestructura física requiere de la interacción entre los dominios virtuales y
físicos. En otras palabras, los controladores de las cuatro jerarquías 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 Capítulo
6.1. Por lo tanto el diseño de una arquitectura global de cooperación entre
jerarquías de controladores es en sí una tarea difícil.
La cuestión del control en banda y fuera de banda también es importante en
el diseño 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 energía; mientras que el controlador dentro de la banda está más ocupado
por los problemas de rendimiento. En general, es posible que las
funcionalidades en banda y fuera de banda tengan sus propias jerarquías, cada
una suministrada por un proveedor diferente. La coordinación entre las dos
partes en éste caso es compleja, pero esencial para una gestión eficaz.
Debido a su naturaleza modular, los activos del centro de datos se pueden
mover fácilmente, y por lo general lo hacen por una variedad de razones. En un
centro de datos grande, es difícil hacer un seguimiento de estos activos. Así, la
gestión de activos se ha convertido en un problema importante en los centros
de datos y soluciones para la localización de los servidores en un centro de
datos se utilizan con frecuencia. El estándar USB inalámbrico emergente puede
ser explotado para la localización y referencia precisa de activos y se basa en él
para proporcionar servicios basados en la ubicación en el centro de datos.
50
7 Requisitos de la Gestión de Recursos en Centros de Datos
En éste Capítulo trataremos los requerimientos del software para la Gestión
y Administración de recursos en Centros de Datos, considerando los aspectos
relacionados con la Monitorización, Análisis de Datos, Toma de Decisiones y
Automatización de Tareas. Posteriormente, discutiremos la evolución de las
herramientas de arquitectura abierta para la gestión de CPD.
Es común hoy en día administrar el uso compartido de la red a través de
middleware o software de gestión de los recursos disponibles. La elección
arquitectónica de virtualizar a nivel de infraestructura es una totalmente nueva
dirección 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 abstracción.
Por ejemplo, un usuario puede obtener una instancia de máquina 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 abstracción de máquina ofrece a los usuarios
acceso a la carta y el control sobre entornos computacionales personalizados.
Los sistemas de computación virtuales también pueden ofrecer garantías de
comportamiento predecible y el aislamiento de otros usuarios, utilizando
tecnologías de virtualización para controlar la unión de los entornos de los
huéspedes a los recursos físicos 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 más cercana a la de hardware,
nos referimos a esta capa de control como ‘underware’ para distinguirla de
middleware clásica. Una característica 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 más 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 gestión, y facilitar el acceso.
A medida que los centros de datos crecen en tamaño y proliferan, hemos
visto una amplia gama de aplicaciones que evolucionan para tomar ventaja de
51
este entorno. Servidores Web con múltiples niveles, aplicaciones de renderizado
multimedia, simulaciones a gran escala, y otras cargas de trabajo orientadas a
servicios son ya escalables a un gran número 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 eléctrica los
aires acondicionados de las salas de ordenadores, además de tecnología de TI
tradicional. Los usuarios deben gestionar las aplicaciones que se pueden
ejecutar en el hardware compartido, incluidas las máquinas virtuales y las redes
de área local virtuales y en entornos heterogéneos. La magnitud de este desafío
ha motivado el trabajo reciente en marcos de supervisión y control coordinada
de las infraestructuras de computación a gran escala. Los enfoques más
comunes se basan en controlar, analizar, planear y ejecutar lazos de control.
Una infraestructura de instrumentación registra lecturas de los sensores, que
se someten a análisis de datos. Los resultados del análisis se alimentan a un
motor de políticas, que crea un plan de cómo 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 rápida. Por
ejemplo, los ambientes comerciales tales como OpenView y Tivoli información
agregada presentan una supervisión gráfica y una interfaz de control a los
administradores a partir de una variedad de fuentes de información.
La investigación reciente se centra en extender el estado de la técnica a tres
aspectos importantes. El primero, hacia los sistemas a escala de Internet, a
menudo usando una metáfora sensores para la instrumentación, el
aprovechamiento de la investigación en redes de sensores de gran escala y las
consultas en sensores de infraestructuras área amplia como PlanetLab.
Figura 16. Gestión de Infraestructura : Capa de Control (Underware)
52
El segundo es el desarrollo de herramientas de análisis para reconocer
patrones y diagnosticar anomalías en los datos. Por último, dado que los
operadores humanos pueden ser incapaces de evaluar los eventos lo
suficientemente rápido como para responder con eficacia, hay un creciente
interés en "cerrar el círculo" con herramientas para planificar las respuestas, y
ejecutar la gestión del sistema a través de interfaces de programación
(actuadores). Este es un objetivo clave a largo plazo de las iniciativas de
computación autonómica y las empresas de adaptación respectivamente. Estas
tendencias se combinan en la idea de un "plano de conocimiento" para otros
sistemas de gran escala e Internet.
La información física tiene un papel importante que desempeñar en la
supervisión y control dinámico para la automatización del centro de datos y,
sobre todo cuando se combina con las métricas de rendimiento. Como un
ejemplo motivador, consideremos la necesidad de administrar la energía y la
refrigeración en un centro de datos. El costo de la energía para alimentar y
enfriar el equipo de un gran centro de datos es significativa. Por otra parte,
tendencias de la tecnología están impulsando el aumento de densidad de
potencia, en parte, para reducir los costes de espacio y cableado. Como
resultado, la infraestructura para la alimentación y la refrigeración es crítica
para la fiabilidad del servicio.
El consumo de recursos y la refrigeración son esenciales. La instrumentación
combinada es un requisito previo del control inteligente para ajustar la
infraestructura de refrigeración controlada por software, a modo de equilibrar
la carga térmica y mejorar la eficiencia energética, o predecir fenómenos
térmicos y responder mediante la migración de cargas de trabajo o de
almacenamiento.
Un desafío fundamental que enfrentan estos proyectos, sin embargo, es cómo
llevar a cabo experimentos científicos eficaces que permitan conocer estos
nuevos entornos. Hay una escasez de métodos e instrumentos para obtener
datos y comprender las interacciones entre objetos en el centro de datos, desde
los componentes de bajo nivel para el desempeño de las aplicaciones de alto
nivel, para luego validar o rechazar hipótesis sobre cómo estos componentes
responden a cambios y optimizaciones futuras. Si vamos a aplicar el método
científico a la gestión de centros de datos, debemos contar con las herramientas
adecuadas para llevar a cabo experimentos repetibles y verificables, y medir los
53
resultados.
7.1 Monitorización Los Centros de Datos se han convertido en el corazón de las actividades de
negocio de las organizaciones. Sus complejas infraestructuras, en las que
convergen lo físico 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 parámetros necesarios para que estos
Centro de Datos ofrezcan servicios de calidad y sean capaces de estar
preparados para futuros requerimientos, adaptándose a las nuevas tecnologías
y reglamentos, al tiempo que se mantiene estable el control de costos, se mejora
la productividad, se reduce el consumo energético y se consigue un mejor
aprovechamiento de los recursos.
Es por esto, que se hace necesario e imprescindible prestar una especial
atención a todas las infraestructuras del Centro de Datos y proceder a su
monitorización, tanto interna como externa.
Un Centro de Datos bien administrado está preparado para responder ante
las eventualidades, permite una rápida posición ante la toma de decisiones y no
compromete la disponibilidad. Las instalaciones que implementen soluciones
de monitorización serán las que presenten unas instalaciones más adaptables,
económicamente sostenibles y ecológicamente eficientes.
Las herramientas de DCIM (Data Center Infrastructure Management)
proporcionan una completa información para gestionar los recursos críticos de
un Data Center, permitiendo que sus responsables puedan definir objetivos de
rendimiento que respalden las operaciones globales de la organización.
Figura 17. Integrated Data Center Infrastructure Management
54
Con las soluciones de DCIM se localizan, visualizan, identifican y
administran los recursos físicos del Data Center (servidores, rack, sistemas de
almacenamiento, de energía y refrigeración...), así como virtuales; al tiempo que
se obtiene información para medir, monitorizar, gestionar y controlar el
rendimiento del consumo de energía de las estructuras.
De esta forma, es posible mejorar la productividad, reducir los costes y
optimizar la capacidad de planificación para un futuro crecimiento, ya que se
consigue un control más eficaz de todos los activos.
Una solución de DCIM debe ofrecer una visión holística, que permita la
mejora continua de la infraestructura crítica, que aporte una visión global y en
tiempo real de toda la instalación, tanto de la infraestructura informática
(virtual, física y las cargas de trabajo a nivel de software) como del entorno de
instalación (alimentación eléctrica, enfriamiento, etc.). De esta forma, se podrá
conocer la localización, 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, además de los aplicativos necesarios para buscar, documentar y
visualizar los sistemas físicos y virtuales. La automatización es otra de las claves
de estas soluciones y, por eso, la mayoría de estos productos incluyen
funcionalidades automáticas que facilitan la creación y gestión de la base de
datos y otras prestaciones que agilizan los procesos.
El Sistema de monitorización de señales y alarmas de las infraestructuras nos
muestra y gestiona la información 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. Gestión de IT y Servicios de Negocio (DCIM)
55
La información recopilada debe ser transmitida de forma inmediata para que
los interesados puedan intervenir. Las maneras más habituales son mediante IP
Webserver, envío de e-mail, envío de SMS, envío de traps y centralización en
gestores de edificios, etc.
Algunas de las alarmas deben ser capaces de interactuar con otros equipos
para la minimización de daños como puede ser el apagado automático de
servidores (Shut Down), actuación de contactores y relees y actuación en electro
válvulas.
Características como el registro de logs deben estar consideradas para tener
un control sobre los eventos ocurridos.
Los principales beneficios de este sistema de monitorización centralizada
para el cliente son:
• Información 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
• Anticipación ante posibles incidencias
• Disminución del tiempo de respuesta en caso de incidente mediante el
envío instantáneo de alarmas y avisos
7.2 Análisis de Información en Tiempo Real A medida que los sistemas de TI de la empresa responden a los cambios de
los últimos años, se hace cada vez más importante repercutir estos cambios en
los métodos y herramientas destinados a la instrumentación de sistemas,
análisis, respuesta y emulación. En particular, atendiendo dos necesidades
fundamentales : la necesidad de métodos de vigilancia que aborden de manera
integral la instrumentación del sistema desde los dominios de TI y hasta los
emplazamientos en donde estos se encuentran; y la necesidad de una emulación
más detallada y flexible de los actuales ambientes consolidados de multi-
usuarios y multi-aplicaciones.
Para hacer frente a la primera necesidad, es comúnmente utilizada la noción
56
de planos conocimiento, ampliados para incluir información de ubicación
espacial e información de los sensores ambientales. Las arquitecturas
propuestas incluyen comunicación 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, diseñada para fácil 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 análisis de datos más
amplios en un marco de reproducción. Las capturas de análisis de datos
atribuyen tendencias de comportamiento y propiedades de correlación entre los
atributos a través del uso de técnicas matemáticas (modelos ocultos de Markov,
EM clustering, etc.) que permiten capturar y condensar importantes
propiedades de los registros estadísticos de comportamiento del sistema. Estas
herramientas de reproducción de datos buscan recrear las condiciones de uso
de recursos de interés específic. Como ejemplo de este tipo de herramientas, se
encuentra la aplicación SeASR.
7.3 Evolución de las Arquitecturas abiertas en la Gestión de Recursos La combinación de recursos disponibles en los centros de datos actuales
ofrecen beneficios tangibles y convincentes. A pesar de ello, la tecnología para
su eficaz gestión está en una etapa temprana. La computación virtual es un
nuevo segmento de mercado, así como una zona rica para la investigación.
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 términos generales a una amplia gama de entornos de computación,
incluyendo los sistemas existentes de middleware, computación en malla y en
clúster, los servicios Web y sistemas aún por crearse.
Todo ello motiva a un mayor énfasis en las implicaciones de las políticas 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 gestión de sistemas. Es sencillo exponer estas
opciones a operadores humanos a través de un panel de control, pero el gran
desafío es una autogestión de utilidad de computación en el que las funciones
de control son automatizadas y responden a los cambios en tiempo real. El
diseño de políticas de gestión de recursos es complejo, debido al menos a tres
razones :
57
1. Es heurística. La gestión de recursos implica proyecciones bajo
incertidumbre y problemas de optimización que son NP-completo en su forma
general, lo que nos obliga a adoptar heurísticas adaptadas a las necesidades y
configuraciones específicas. No existe una solución de "talla única".
2. Es dinámica. Las políticas de asignación de recursos deben adaptarse a
las nuevas cargas de trabajo y las demandas en tiempo real.
3. Es orgánica y emergente. Las decisiones en las políticas de gestión deben
equilibrar las necesidades e intereses de los múltiples actores independientes,
por ejemplo, los proveedores de recursos y consumidores de recursos o
huéspedes alojados. En general, la asignación de recursos surge de decisiones
tomadas por cada uno de estos actores, y las complejas interacciones de esas
decisiones.
La estructura básica de la política de gestión de recursos es común a una
serie de visiones de computación virtual en red, que abarca los centros de
gestión de datos, bancos de pruebas de red, sistemas de grid computing y
diversas utilidades disponibles en el mercado.
Mediante un balance adecuado de políticas y el mecanismos, estos sistemas
pueden basarse en la misma gestión de recursos de los sustratos subyacentes.
La mayor parte de las diferencias entre los enfoques de gestión tienen que
ver con cuestiones relacionadas con las políticas implementadas, o cuestiones
relacionadas con quiénes son los participantes y la cantidad de energía que
consumen, o diferentes supuestos de aplicación que en última instancia tienen
poco impacto en los requisitos de gestión de los recursos disponibles. Estas
diferencias superficiales dejan abierta la posibilidad de una gestión común. En
particular, a medida que aumentan las utilidades de red, el control basado en
arquitecturas abiertas se convierte en atractivo como base para la adjudicación
de recursos flexible y adaptable.
58
8 OpenQRM : Plataforma Abierta de Gestión de Centros de Datos
En éste Capítulo desarrollaremos la propuesta de arquitectura de gestión 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 gestión y
mantenimiento. La complejidad se origina a partir del número de subsistemas
que intervienen y de la complejidad de cada subsistema. En un centro de datos
moderno, siempre hay un buen número de subsistemas que participan como
servidores físicos, máquinas virtuales, diferentes sistemas operativos,
componentes, configuraciones y servicios de red; además de un control de los
sistemas y los servicios, gestión fuera de banda y así sucesivamente. Resulta
conveniente la gestión centralizada de todos los diferentes aspectos en una sola
consola de administración, que es exactamente el objetivo del marco
OpenQRM.
OpenQRM es una plataforma de código abierto de nueva generación para la
administración de centros de datos. Su arquitectura totalmente conectable se
enfoca en el despliegue automático, rápido y basado en dispositivos, monitoreo,
alta disponibilidad, computación en la nube, copia de seguridad y
especialmente en apoyar y conformar tecnologías de virtualización múltiple.
OpenQRM es la única solución del mercado que unifica estos servicios en una
única aplicación 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 administración la gestión tanto de las máquinas
físicas cómo de las virtuales y permite automatizar y medir la actividad en los
centros de datos de una forma cómoda y segura. Provee una API bien definida
la cual puede ser usada para integrar herramientas de terceros como
complementos (plugins) adicionales.
El concepto principal detrás de OpenQRM es dividir los centros de datos en
subsistemas manejables. En OpenQRM cada subsistema se administra por
separado a través de un plugin que proporciona la funcionalidad para su
gestión.
59
OpenQRM crea interfaces automatizadas y genéricas entre los diferentes
componentes a través de su arquitectura de software modular. En realidad, el
servidor de base de OpenQRM está diseñado para tener una sola función :
gestionar plugins. De esta manera nuevas características como el despliegue de
recursos adicionales, el almacenamiento y el tipo de virtualización se pueden
agregar a OpenQRM sin cambiar una sola línea de código en el servidor de
base. Mediante éste concepto se mantiene el servidor de base siempre pequeño,
estático y robusto, pero también permite que varios desarrolladores trabajen en
diferentes plugins de forma paralela sin que estos interfieran entre sí.
Figura 19. Interfaz de Gestión OpenQRM
Uno de los principios fundamentales de OpenQRM es proporcionar
interfaces genéricas entre diferentes subsistemas en un entorno de TI de manera
escalable estandarizada, flexible y dinámica, evitando dependencias no
necesarias. Los subsistemas específicos se implementan por cualquiera de los
componentes de terceros mediante plugins o modulos de código abierto o
comerciales, en la capa de abstracción de OpenQRM. Para proporcionar
variedad y preferencias de administración de sistemas específicas, OpenQRM
siempre trata de dar varias opciones con respecto a la implementación de cada
subsistema. Un ejemplo de ello son las soluciones automatizadas de control
compatible e integrado en OpenQRM como nagios3, Zabbix y collectd, más el
propio servicio de monitorización básico de la plataforma.
Las diferentes tecnologías de virtualización y enfoques para unificarlas,
tratan de resolver el mismo problema de específicos (a veces incluso cerrados)
formatos de los discos duros virtuales. El hecho de que todas las tecnologías de
60
virtualización utilicen su propio formato de disco duro virtual hace que los
sistemas de migración a otra tecnología de virtualización, o incluso volver al
sistema físico, sea una tarea compleja.
Para mitigar esta complejidad, OpenQRM proporciona una capa de
virtualización unificada que se encuentra en la parte superior de cada
tecnología de virtualización y que permite realizar ajustes directamente en el
servidor OpenQRM. En OpenQRM las imágenes (servidor) se conectan
directamente desde el almacenamiento, a través de la red, a las máquinas
virtuales de cualquier tipo. A través de este OpenQRM la capa de
virtualización unificada admite la migración sin problemas de los sistemas
físicos a máquinas virtuales (P2V), de las máquinas virtuales de vuelta a los
sistemas físicos (V2P) y también la migración de la tecnología de virtualización
de la A a la tecnología de virtualización B (V2V).
OpenQRM también proporciona facilidades de gestión de los subsistemas de
almacenamiento mediante la integración con varias tecnologías de
almacenamiento como NFS, iSCSI, AoE (Coraid), Equallogic, NetApp y ZFS.
8.1 Concepto, Diseño y Arquitectura Una cuestión importante acerca de los centros de datos es : ¿Estamos
tratando con "servicios" o "servidores"?
¿Es importante para nosotros que el hardware físico específico (o virtual)
siga trabajando o es más 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 interrupción 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 restauración.
La administración de un data center con todos sus componentes es una tarea
que sobrecarga y excede las capacidades de una sola aplicación. La
automatización y alta disponibilidad sólo puede trabajar bien si todos los
componentes están bien integrados y cooperan de una manera definida. El
61
resultado es aún más 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 más o menos sólo administra los complementos. La base
también provee el framework con el que los complementos interactúen (por
ejemplo recursos, imagen, almacenamiento,… objetos) pero todas estas
características de OpenQRM están provistas por sus complementos.
Esto trae ciertos beneficios:
• Desarrollo rápido 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.
• Fácil integración con componentes de terceros a través de una API de
complementos bien definida.
• Errores en un complemento no dañan al sistema base.
• Menor complejidad debido a que el complemento administra sólo su
propio ambiente.
• Menos código en el motor de base: menos código significa menos errores.
• Mejor escalabilidad debido a que sus complementos pueden ser
habilitados/inhabilitados sobre la marcha.
Los complementos son fáciles de desarrollar gracias al framework de base
provisto.
Mediante una arquitectura única, OpenQRM proporciona una capa de
abstracción Datacenter-genérico que separa completamente los "servicios" de
los servidores físicos o máquinas 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 también son modulares
en OpenQRM, puede utilizarse cualquier tipo de dispositivo de
62
almacenamiento externo o remoto.
En OpenQRM, todos los servicios provistos son integrables a una intefaz
centralizada mediante ‘plugins’ o módulos, permitiendo una capa de
abstracción que facilita la gestión de los servicios sin necesidad de interactuar
de forma directa con los equipos involucrados en la prestación del servicio.
8.2 Aprovisionamiento – El modelo de Recursos OpenQRM OpenQRM contiene una completa implementación genérica de capa de
abstracción y modelo de recursos que se ajusta al aprovisionamiento de
sistemas físicos y máquinas virtuales de cualquier tipo. Lo primero que debe
hacerse para desplgar una imagen de servidor para un servidor físico es la
integración de sus recursos en el ambiente OpenQRM. La adición de un nuevo
recurso físico para OpenQRM se efectúa a través de una interfaz gráfica de fácil
uso.
Mediante la utilización de "network-boot" (PXE) en el BIOS de los servidores
OpenQRM puede detectarlos automáticamente y añadirlos a la intefaz de
gestión. Como se explica en detalle en el Capítulo siguiente, el servidor
arrancará de forma automática a través de la red y aparecerá como un nuevo,
recurso "inactivo" en la lista de recursos de OpenQRM.
A través de los módulos de virtualización de OpenQRM las máquinas
virtuales se crean y agregan a OpenQRM de manera similar a la de un servidor
físico. Las máquinas virtuales de diferentes tipos son creadas a través de la
interfaz VM-Manager que permite configurar diversos parámetros de VM,
como el nombre de la VM, la cantidad de memoria, el número de CPUs y la
conexión de red. La secuencia de arranque de máquinas virtuales se ajusta
entonces a "netboot" (PXE), lo que les permite ser añadidas a OpenQRM en la
misma forma que los sistemas físicos. Aparecerán en la lista de recursos
OpenQRM como nuevo, recurso “inactivo” del tipo de máquina virtual
específica.
Todo el aprovisionamiento y la implementación se controla en la sección
Menú de OpenQRM "Base" mediante un modelo de máquina o sistema. El
modelo de la máquina convierte los complejos flujos de trabajo de la
implementación de un nuevo sistema de acuerdo con un grupo de parámetros
de configuración, los requisitos y SLAs mediante una sola acción.
63
8.3 Capa de Almacenamiento Dado que los métodos de despliegue rápido de OpenQRM se basan en
sistemas de almacenamiento centralizados, constituyen un componente clave en
la red de gestión OpenQRM. La capa de almacenamiento en OpenQRM
proporciona al servidor la ubicación de la imagen remota. Dependiendo del
tipo de almacenamiento esta ubicación de imágen puede ser un NFS-export, un
LUN iSCSI, un volumen AOE o cualquier otro dispositivo que contenga un
contenido de raíz del sistema de archivos válido.
Al igual que en el caso de los servidores, el sistema de gestión
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 implementación de un servidor de almacenamiento de imágenes a
un recurso "inactivo" existente.
OpenQRM unifica y automatiza la administración de los diferentes recursos
de almacenamiento mediante su interfaz de gestión de almacenamiento
integrado. Por lo tanto, durante la fase de diseño de OpenQRM, el equipo de
desarrollo dedico especial atención 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 módulo de almacenamiento específico para el tipo de tecnología
utilizada, y expuestos a través de un gestor de volúmenes.
El rápido despliegue de OpenQRM tiene su origen en la gestión centralizada
de recursos a través de la red y la facultad de iniciar los sistemas directamente
desde el almacenamiento remoto conectado a la plataforma de gestión. Para
asegurar la gestión de la red y de almacenamiento, y para asegurar que sólo el
recurso dedicado a un equipo específico pueda ser accedido desde una
ubicación remota, OpenQRM se encarga automáticamente de autenticar el
recurso y comprobar los permisos de acceso de los dispositivos que solicitan
acceso. Esto ocurre a través del módulo Auth-Hook proporcionado por el gestor
de almacenamiento. El ‘hook’ de autenticación incluye todos los parámetros de
configuración y la información sobre el recurso que es utilizada por el plugin de
almacenamiento específico (según la tecnología de almacenamiento utilizada)
para habilitar o deshabilitar el acceso.
64
8.4 Gestor de Virtualización La virtualización se gestiona a través de la interfaz de modelaje de máquinas
virtuales. El tipo de recurso específico en la configuración de la máquina
virtual indica la interfaz que utilizará OpenQRM para gestión. Por esta razón, el
host de virtualización debe estar integrado y disponible en OpenQRM. Esto se
puede hacer mediante la implementación de un servidor host de virtualización
que esté enlazado a un recurso de "inactivo" existente. En los casos en que sea
requerido gestionar un host de virtualización existente, éste puede ser
fácilmente integrado a través del módulo “local-server”.
No sólo los tipos de almacenamiento, sino también los tipos de virtualización
son totalmente modulares en OpenQRM. A través de sus plugin de API abierta
OpenQRM se integra con VMware ESX, VMware Server, Xen, KVM y Citrix
XenServer. Se ha añadido soporte para nuevas tecnologías de virtualización
como VirtualBox, OpenVZ y otros. Para ser capaz de manejar sin problemas
todos los diferentes tipos de máquinas virtuales, OpenQRM dispone una capa
en la parte superior de los métodos de virtualización para unificar su gestión.
Las máquinas virtuales en OpenQRM pueden ser iniciadas en el entorno de
gestión, de la misma forma que los sistemas físicos.
En un entorno OpenQRM, un hipervisor se convierte en "sólo" un proveedor
de recursos, siendo responsable de hospedar el recurso de computación virtual
seleccionado por el usuario.
De ésta manera el sistema que se ejecuta en una máquina virtual tiene total
independencia de su Host hipervisor y puede migrado a otros hipervisores de
la misma o diferente tecnología de virtualización o incluso de sistemas físicos a
máquinas virtuales y viceversa. OpenQRM soporta P2V, V2P, y V2V;
permitiendo la migración P2P sin ningún cambio en la configuración de la
imagen provista para el sistema.
OpenQRM no sólo puede gestionar diferentes tipos de tecnologías de
hipervisor sino que también puede implementar a través 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 según lo exigido, con sólo añadir (o eliminar) hipervisores.
8.5 Monitorización OpenQRM dispone de un cliente de monitorización, instalado
65
automáticamente en todos los sistemas gestionados en la red OpenQRM a
través de el sistema base, que incluye una utilidad de seguimiento. Este monitor
consiste en un shell script que envía las estadísticas al servidor OpenQRM a
través del protocolo HTTPS. Las estadísticas incluyen datos de tiempo de
actividad, carga, modelo y número de CPUs, número de interfaces de red y el
tráfico asociado, memoria, swap, etc. OpenQRM reúne esas estadísticas y las
ingresa en su base de datos.
8.5.1 Nagios Nagios es una herramienta de monitorización bien conocida, probada y
ampliamente utilizada, que está disponible para OpenQRM mediante un
módulo integrable adicional. La combinación de la monitorización mediante
Nagios y la gestión de errores automatizados, centro crea un entorno potente y
dinámico que reduce al mínimo 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 código abierto. El
servicio y el programa de monitoreo de la red está basado en el concepto de
cliente / servidor. El servidor Nagios obtiene información 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 información 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á diseñada en forma de módulo integrable. Controles
activos y pasivos de nuevos servicios se pueden agregar fácilmente mediante la
66
creación 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 través 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. También
supervisa los recursos del sistema, como la carga de CPU, el uso de memoria y
disco, procesos en ejecución, 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 estadísticas de
rendimiento del sistema periódicamente y proporciona mecanismos para
almacenar los valores en ficheros RRD. La integración de collectd como un
plugin de OpenQRM proporciona una configuración automática del servidor
collectd y el cliente en todos los dispositivos gestionados dentro de la red
OpenQRM. Los Clientes collectd envían información estadística al servidor
collectd principal que se ejecuta en el servidor OpenQRM. Los gráficos
generados a partir de las estadísticas del sistema están integrados en la interfaz
de usuario OpenQRM y también está disponible para los usuarios de sistemas
virtualizados gestionados.
8.5.3 Zabbix Zabbix es una muy nueva herramienta de supervisión de sistemas que se
caracteriza por su gran capacidad de ampliación y escalabilidad. Es una
solución de monitorización de clase empresarial de código abierto, también
disponible en OpenQRM como un plugin adicional.
Figura 21. Interfaz de Monitorización Zabbix
67
El plugin Zabbix proporciona un servidor automatizado y la configuración
de cliente para los dispositivos gestionados por OpenQRM. Los clientes Zabbix
son detectados automáticamente por el servidor Zabbix a través 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 gestión de servicios y el
almacenamiento disponible en una o más redes. Para instalaciones de
producción, se recomienda adaptar algunas consideraciones de seguridad para
proteger la información transmitida entre los diversos recursos gestionados y el
servidor base de OpenQRM.
Toda la comunicación HTTP entre un navegador del cliente y la interfaz de
usuario OpenQRM Server es cifrada vía SSL. También la comunicación interna
entre el Cliente OpenQRM (por ejemplo, para el envío de estadísticas) utiliza
éste protocolo.
Para mejorar la seguridad de la red, se recomienda la implementación de un
cortafuegos con filtrado de paquetes entre la red de gestión y la red de
servicios. Las reglas del firewall se pueden adaptar dinámicamente de acuerdo
con los requisitos de tráfico en la red de los recursos computacionales y de
almacenamiento.
Para mejorar aún más la seguridad de la red, puede implementarse el
etiquetado de VLAN a modo de proporcionar una separación de la red física
completa para los sistemas gestionados en OpenQRM.
Para poner en práctica las reglas de firewall personalizadas para los
dispositivos administrados, se recomienda la creación de ficheros de
configuración o ‘recipes’ que establecen las configuraciones de firewall
específicas según los servicios ofrecidos por los dispositivos. Estos recipes se
pueden asignar manualmente a los dispositivos gestionados mediante la
interfaz de gestión (OpenQRM Puppet plugin) o se aplican de forma automática
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 través de la integración nagios3. Este modo
68
especial de Nagios mostrará exactamente los servicios de red que están
disponibles en el entorno administrado OpenQRM. Para obtener información
detallada de los servicios disponibles se recomienda utilizar los plugins collectd
y Zabbix disponibles en OpenQRM.
8.7 Desarrollo e Integración de Módulos Adicionales La arquitectura modular de OpenQRM está diseñada para apoyar
plenamente la integración de nuevas funcionalidades. A través de en un marco
estático de gestión, se permite la integración de diferentes plugins para su
utilización en paralelo. OpenQRM dispone de características de construcción y
embalaje (packing) de módulos, modos de prueba para diversos niveles de
interacción con el sistema base, depuración, etc.
8.8 Recomendaciones : Crítica y propuestas de avance sobre la solución provista por OpenQRM
Nos encontramos en tiempos de cambios importantes en la definición de
arquitecturas abiertas para la gestión de recursos informáticos. OpenStack,
OpenNebula, Proxmox, entre otras iniciativas, se están posicionando como
alternativas de código abierto para la provisión y administración de recursos
basados en Cloud.
OpenQRM constituye una aproximación a la gestión 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
estandarización de procesos de gestión de recursos, que permitan una interfaz
común de interacción entre los diversos niveles de abstracción definidos por las
soluciones de arquitectura abierta, a modo de que el modelo de capas analizado
en capítulos anteriores pueda ser efectivamente implementado y que la gestión
de recursos físicos geográficamente distribuidos sea eficiente (compromiso de
eficacia).
Una de las mejoras a implementar en OpenQRM, serían los llamados Centros
de Datos ‘Federados’, que pongan a disposición sus recursos en la red para ser
utilizados en la abstracción de Centro de Datos virtuales, con activos
distribuidos, discutido previamente. Sería conveniente contar con un canal
comunicación entre los ‘Federados’ provisto en la misma plataforma, a modo de
que conjuntamente con información de negocio relevante, pueda gestionarse la
69
provisión, y consecuentemente la administración de recursos más adecuada
según ubicación geográfica, poder de cómputo, tiempos de acceso, entre otros.
Ante la diversidad de soluciones de arquitectura abierta provistas, se hace
cada vez más necesario definir mecanismos de interacción que permitan la
transparente migración de la información de gestión del recurso entre
diferentes plataformas de gestión, a modo de facilitar la implementación de
CPDs virtuales y la federación o agrupamiento de recursos geográficamente
distribuidos.
70
9 Prueba de Concepto : Integración de Gestión de VLANs
Como hemos indicado previamente, OpenQRM permite al integración de
módulos desarrollados por terceros, que conjuntamente con la arquitectura
abierta ofrecida por el sistema base, ofrecen la posibilidad de crear nuevas
funcionalidades de gestión y administración de forma transparente, ampliable y
escalable. Las interfaces de programación entre los módulos y el sistema base,
se proporcionan bajo el esquema de Licencia GPL; de forma que el código se
encuentra disponible para ser consultado o modificado según las funcionalidad
requeridas por el Centro de Datos.
Como prueba de ello, hemos tomado el código fuente de la Aplicación ‘HP
VLAN Administration’ y se han agregado funcionalidades específicas, como la
autenticación mediante PAM (Pluggable Authentication Module) disponible en
Linux. Hemos igualmente integrado la utilidad ‘ShellInABox’, que permite la
ejecución de un programa residente en el servidor de administración, y ofrece
una interfaz web de ‘línea de comandos’, a modo de gestionar de forma directa
múltiples comandos disponibles en el sistema desde una ubicación remota; en
particular los comandos SNMP requeridos para la configuración de Switches
HP Procurve.
En nuestro caso, hemos utilizado Apache versión 2.4 como servidor Web y el
paquete de desarrollo PHP versión 5.3.15. El sistema operativo utilizado fue
MacOS X Server versión 10.8.3.
Figura 22. Gestión web de VLANs en Switches HP ProCurve
9.1 HP VLAN Administration La aplicación ‘HP VLAN Administration’ está disponible gratuitamente en la
web (SourceForge). Está escrita en lenguaje PHP y se ejecuta en el servidor de
gestión Web mediante CGI. La configuración de los switches es realizada en
una interfaz gráfica dispuesta por la aplicación y accesible a través de la web,
71
con diferentes mecanismos de autenticación. Desde la interfaz gráfica es
posible enviar diversos comandos SNMP, en múltiples 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 línea 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 ningún tipo de plugins de
navegación adicionales.
9.3 Integración en OpenQRM y Escalabilidad Tanto la aplicación ‘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
código de ambas aplicaciones bajo el entorno de ejecución, de forma que
puedan ser accedidas desde la interfaz Web base de OpenQRM como un
módulo activable según el requerimiento del administrador.
72
Conclusiones
Los centros de datos son por naturaleza ambientes personalizados y
complejos. Se requiere de considerable esfuerzo para su gestión y
mantenimiento. La complejidad se origina a partir del número de subsistemas
que intervienen y de la complejidad de cada subsistema. En un centro de datos
moderno, siempre hay un buen número de subsistemas que participan como
servidores físicos, máquinas virtuales, diferentes sistemas operativos,
componentes, configuraciones y servicios de red; además de un control de los
sistemas y los servicios, gestión fuera de banda y así sucesivamente. Resulta
conveniente la gestión centralizada de todos los diferentes aspectos en una sola
consola de administración.
Las aplicaciones de centros de datos implican cada vez más el acceso
conjuntos masivos de información, minería de datos (Data Mining) en tiempo
real y transmisión en ‘streaming’ que imponen grandes exigencias a la
infraestructura de procesamiento, conectividad y almacenamiento.
Varias fuerzas están dando forma al paisaje del centro de datos y esperamos
que los futuros centros de datos sean mucho más que simplemente versiones
más 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 difíciles.
En el presente trabajo hemos definido un modelo de capas para este tipo de
centros de datos y se proporciona un análisis detallado del estado de la técnica
y los nuevos desafíos en la gestión y administración del almacenamiento, los
recursos computacionales y las redes.
Hemos propuesto una Arquitectura Abierta para la gestión y administración
de recursos en Centros de Datos. El ámbito de pruebas se ha limitado a integrar
diversas herramientas de gestión en una plataforma única de administración, a
modo de probar que la arquitectura abierta de OpenQRM permite conjugar
diversas funcionalidades en una misma interfaz de gestión, de forma
transparente, dinámica y escalable.
La utilización de una arquitectura abierta facilita la gestión y administración
de recursos en centros de datos, permitiendo que nuevas funcionalidades
puedan ser agregadas sin interferir con los procesos ya implementados;
73
disminuyendo de forma considerable los costes asociados sin poner en riesgo la
operatividad y los servicios provistos.
La plataforma de gestión OpenQRM provee de la flexibilidad y la
escalabilidad necesaria para los múltiples servicios ofrecidos por los centros de
datos modernos, permitiendo la inclusión de nuevos servicios a medida y la
funcionalidad de soluciones de gestión previamente implementadas, mediante
su inclusión en la plataforma a través de módulos o plugins.
Observamos que conjuntamente con OpenQRM, existen otras soluciones que
ofrecen la gestión de recursos en Centros de Datos, desde la administración de
servidores físicos y equipos de red; hasta recursos basados en Cloud. Ante la
diversidad de soluciones de arquitectura abierta provistas, se hace cada vez
más necesario definir mecanismos de interacción que permitan la transparente
migración de la información de gestión del recurso entre diferentes plataformas
de gestión.
74
Bibliografía
[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
75
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