Universidad O&M

(Organización & Método)

NOMBRES Y MATRICULAS
Víctor Ariel Perez Perez 19-SISN-6-002
Edwin Nina 19-SISN-6-010
Pedro Rodríguez 19-SISN-6-028

CARRERA
Ing. En Sistemas y Computación

MATERIA
INTRODUCCION A LA GESTION DE CENTROS DE DATOS

TEMA
Bloque 4: Administración avanzada de sistemas II: Entornos de “servicios globales”
Bloque 5: Administración avanzada de sistemas III: Clustering

PROFESOR
ELVIN RAFAEL RAMON ARAUJO
 Investigar y Desarrollar los Bloques 4 y 5

Bloque 4: Administración avanzada de

sistemas II: Entornos de “servicios globales”

4.1 Servicio seguro centralizado de información del “Data Center” (PDC):

 Servicio seguro de información: OpenLdap (ssl)

 OpenLDAP: es la implementación libre del protocolo LDAP. Tiene su propia licencia y es

compatible con otros servidores que utilicen el mismo protocolo. Es utilizado por distintas
distribuciones Linux y BSD.

Características de OpenLDAP

OpenLDAP incluye un número de características importantes.

Soporte LDAPv3 — OpenLDAP soporta la Capa de autenticación y seguridad (SASL), la Seguridad de
la capa de transporte (TLS) y la Capa de conexión segura (SSL), entre otras mejoras. Muchos de los
cambios en el protocolo desde LDAPv2 han sido diseñados para hacer LDAP más seguro.

Soporte IPv6 — OpenLDAP soporta la próxima generación del protocolo de Internet versión 6.

LDAP sobre IPC — OpenLDAP se puede comunicar dentro de un sistema usando comunicación
interproceso (IPC). Esto mejora la seguridad al eliminar la necesidad de comunicarse a través de la
red.

API de C actualizada — Mejora la forma en que los programadores se conectan para usar
servidores de directorio LDAP.

Soporte LDIFv1 — Provee compatibilidad completa con el formato de intercambio de datos, Data
Interchange Format (LDIF) versión 1.

Servidor Stand-Alone mejorado — Incluye un sistema de control de acceso actualizado, conjunto

de hilos, herramientas mejoradas y mucho más.
  Servicio de autenticación: Kerberos

Es un protocolo de autenticación de red que está diseñado para proveer una autenticación fuerte
para las aplicaciones cliente-servidor. Este servicio de autenticación (validación de identificación)
fue desarrollado en el Massachusetts Institute of Technology (MIT) en 1987 como una solución a
los problemas de seguridad de la red. El protocolo Kerberos utiliza criptografía fuerte para que un
cliente pueda proveer su identidad a un servidor (y viceversa) a través de una conexión de red
insegura.

Kerberos, llamado así por el perro guardián de tres cabezas de la mitología griega, es un protocolo
de autenticación de red creado por MIT. Kerberos utiliza la criptografía de clave secreta para
garantizar la autenticación segura con aplicaciones cliente / servidor incluso en redes no seguras. 

Kerberos está diseñado para evitar completamente el almacenamiento de contraseñas localmente

o tener que enviarlas a través de Internet y proporciona autenticación mutua, lo que significa que
tanto la autenticidad del usuario como la del servidor están verificadas. 

¿Cómo funciona la autenticación Kerberos?

Cada usuario dentro de un sistema, conocido como "principal", comienza con un ticket único.
Estos tickets son emitidos por el servidor de autenticación, también conocido como Centro de
distribución de claves de Kerberos, comúnmente denominado KDC, y se utilizan para identificar los
principales específicos. El boleto está cifrado con una clave secreta y almacena diversos datos
sobre las credenciales del director.

Esta clave secreta es un secreto compartido solo entre el servidor de autenticación y el servidor al
que el cliente está tratando de acceder, por lo tanto, el cliente que solicitó el boleto no puede
conocer ni cambiar ninguno de los contenidos del boleto emitido. Kerberos también utiliza cifrado
de clave simétrica, lo que significa que la misma clave se utiliza para cifrar y descifrar.

El boleto generalmente contiene información sobre el principal,

incluyendo:

 La clave de sesión
 La identificación del usuario solicitante:  este es comúnmente un nombre de usuario
 El servidor / servicio para el que se solicita.
 La dirección IP del lado del cliente del dispositivo que está autorizado para usar el ticket
específico
 El tiempo del boleto hasta el vencimiento (generalmente 10 horas)
 El tiempo de generación del billete.
El administrador del reino de Kerberos (la colección de máquinas y directores) puede impedir la
emisión de tickets para ciertos usuarios, pero no puede revocar un ticket una vez que se ha
emitido. Por lo tanto, es importante que cada boleto tenga un tiempo de caducidad asociado.

Para recibir un ticket, el cliente envía una solicitud al servidor de autenticación que incluye
información sobre el servidor al que desean conectarse. El servidor de autenticación luego verifica
si el nombre de usuario del cliente está en la base de datos de KDC. Si el nombre de usuario es
válido, el servidor de autenticación crea y emite un ticket con una clave de sesión adjunta. Con
este proceso, la contraseña del usuario nunca debe almacenarse de forma no cifrada, ni siquiera
en la base de datos del servidor de autenticación.

¿Por qué la autenticación Kerberos es importante?

Cada vez que la información se envía de un lado a otro a través de Internet, esa información ha
aumentado la exposición a fuentes externas, incluidos posibles atacantes maliciosos. Los piratas
informáticos a menudo utilizan herramientas para intentar eliminar contraseñas de las redes a
medida que éstas se envían de un lado a otro. Debido a esta vulnerabilidad, es mucho más seguro
garantizar siempre que, cuando se envía una contraseña a través de una red, se encripta. La
autenticación de contraseña Kerberos se asegura de que esto sea cierto y también verifica la
identidad del cliente que envía la solicitud.

Los cortafuegos son una buena forma de defensa contra intrusiones externas o piratas
informáticos malintencionados, pero generalmente funcionan bajo el supuesto de que los ataques
provienen de fuera de una red. Esto deja la puerta abierta para los ataques llevados a cabo por
personas que ya tienen acceso a la red. El proceso de autenticación Kerberos, por otro lado,
funciona independientemente de la ubicación de la intrusión potencial.

Cómo ayuda la autenticación Kerberos a Barracuda CloudGen Firewall?

La implementación de la autenticación basada en Kerberos dentro de su red permitirá

que Barracuda CloudGen Firewalls asocie las solicitudes web salientes con los usuarios de Active
Directory, registre la actividad del usuario y aplique políticas específicas del usuario o del grupo a
las conexiones salientes.

 Servicio local de sincronización de “reloj”: NTP

Network Time Protocol (NTP) es un protocolo de Internet para sincronizar los relojes

de los sistemas informáticos a través del enrutamiento de paquetes en redes
con latencia variable. NTP utiliza UDP como su capa de transporte, usando el puerto 123.
Está diseñado para resistir los efectos de la latencia variable.
NTP utiliza el algoritmo de Marzullo con la escala de tiempo Tiempo universal coordinado (UTC),
incluyendo soporte para características como segundos intercalares. NTPv4 puede mantenerse
sincronizado con una diferencia máxima de 10 milisegundos (1/100 segundos) a través de Internet,
y puede llegar a acercarse hasta 200 microsegundos (1/5000 segundos) o más en redes de
área local sobre condiciones ideales.

El demonio NTP de Unix es un proceso de nivel de usuario que se ejecuta continuamente en la

máquina que soporta NTP, y la mayor parte del protocolo está implementado en este proceso de
usuario. Para obtener el mejor rendimiento de NTP, es importante tener un reloj NTP estándar con
lazo de seguimiento de fase implementado en el kernel del Sistema operativo, en vez de solo usar
la intervención de un demonio NTP externo: todas las versiones actuales
de GNU/Linux y Solaris soportan esta característica.
NTP utiliza un sistema de jerarquía de estratos de reloj, en donde los sistemas de estrato 1
están sincronizados con un reloj externo tal como un reloj GPS o algún reloj atómico. Los
sistemas de estrato 2 de NTP derivan su tiempo de uno o más de los sistemas de estrato 1, y
así consecutivamente (cabe mencionar que esto es diferente de los estrato de reloj utilizados
en los sistemas de telecomunicaciones).

 Servicio local de nombres: DNS (Bind9)

Servidores de nombres de dominio (DNS)

El servicio de nombres de dominio (DNS: «Domain Name Service») es un componente
fundamental de Internet: asocia nombres de equipo con direcciones IP (y viceversa), lo que
permite utilizar www.debian.org en lugar de 149.20.4.15 o 2001:4f8:1:c::15.

Los registros DNS se organizan en zonas; cada zona coincide con un dominio (o subdominio) o un
rango de direcciones IP (ya que generalmente se proveen direcciones IP en rangos consecutivos).
Un servidor primario es autoridad sobre los contenidos de una zona; los servidores secundarios,
generalmente en otras máquinas, proveen copias de la zona primaria actualizadas regularmente.

Cada zona puede contener registros de varios tipos (registros de recursos: «Resource Records»),
estos son algunos de los más comunes:

A: dirección IPv4.

CNAME: alias (nombre canónico: «canonical name»).

MX: intercambio de correo («mail exchange»), un servidor de correo. Los otros servidores de

correo utilizan esta información para encontrar a dónde redirigir los emails enviados a una dire
cción particular. Cada registro MX tiene una prioridad. Primero se intenta el servidor con mayor
prioridad, con el menor número (revise el recuadro VOLVER A LOS CIMIENTOS SMTP); se
contactan los demás servidores en orden decreciente de prioridad si el primero no responde.

PTR: asociación de una dirección IP con un nombre. Se almacenan estos registros en una zona de
«DNS inverso» cuyo nombre está basado en el rango de direcciones IP. Por ejemplo, 1.168.192.in-
addr.arpa es la zona que contiene las asociaciones inversas de todas las direcciones en el
rango 192.168.1.0/24.

AAAA: dirección IPv6.

NS: asocia un nombre con un servidor de nombres. Cada dominio debe tener al menos un registro
NS. Estos registros apuntan al servidor DNS que puede responder consultas sobre este dominio;
generalmente apuntan a los servidores primarios y secundarios del dominio. Estos registros
también permiten delegaciones de DNS; por ejemplo, la zona falcot.com puede incluir un registro
NS para internal.falcot.com, lo que significa que otro servidor administra la
zona internal.falcot.com. Por supuesto, este servidor debe declarar una zona internal.falcot.com.

4.2 Servicio seguro de ficheros distribuido (en red):

Un sistema de ficheros distribuido o sistema de ficheros de red es un sistema de archivos de
computadoras que sirve para compartir archivos, impresoras y otros recursos como un
almacenamiento persistente en una red de computadoras. El primer sistema de este tipo fue
desarrollado en la década de 1970, y en 1985 Sun Microsystems creó el sistema de archivos de
red NFS el cual fue ampliamente utilizado como sistema de archivos distribuido. Otros sistemas
notables utilizados fueron el sistema de archivos Andrew (AFS) y el sistema Server Message Block
SMB, también conocido como CIFS.

Un sistema de archivos distribuido va a permitir almacenar y acceder a archivos remotos como si

fueran locales, esto sin notar pérdidas en el rendimiento. Este sistema es útil cuando es necesario
que los usuarios tengan acceso a información compartida en diferentes ubicaciones de forma
ininterrumpida.

Una de las ventajas de este tipo de sistemas es que se puede optimizar la carga de la red para que
los nodos con mucho tráfico deriven recursos compartidos a otras ubicaciones de la red con lo cual
se minimiza el riesgo de cuello de botella y se optimiza la velocidad de acceso a la información.

 Sistema de ficheros en red: NFSv4

Sistema de ficheros en red: NFSv4 4.14. CONFIGURACIÓN DE UN SERVIDOR SÓLO NFSV4

Como administrador del servidor NFS, puede configurar el servidor NFS para que sólo admita
NFSv4, lo que minimiza el número de puertos abiertos y servicios en ejecución en el sistema.

4.14.1. Ventajas e inconvenientes de un servidor sólo NFSv4

En esta sección se explican las ventajas e inconvenientes de configurar el servidor NFS para que
sólo admita NFSv4.
Por defecto, el servidor NFS soporta conexiones NFSv3 y NFSv4 en Red Hat Enterprise Linux 8. Sin
embargo, también puede configurar NFS para que sólo soporte la versión 4.0 y posteriores. Esto
minimiza el número de puertos abiertos y servicios en ejecución en el sistema, porque NFSv4 no
requiere que el servicio rpcbind escuche en la red.

Cuando su servidor NFS está configurado como NFSv4 solamente, los clientes que intentan montar
recursos compartidos usando NFSv3 fallan con un error como el siguiente:

La versión de NFS o el protocolo de transporte solicitados no son

compatibles.

Opcionalmente, también puede deshabilitar la escucha de las llamadas de

protocolo RPCBIND, MOUNT, y NSM, que no son necesarias en el caso de NFSv4 solamente.

Los efectos de desactivar estas opciones adicionales son:

Los clientes que intentan montar recursos compartidos desde su servidor utilizando NFSv3 no
responden.

El propio servidor NFS no puede montar sistemas de archivos NFSv3.

 Sistema de interoperabilidad con plataformas MS Windows: Samba

Samba es una implementación de código abierto del protocolo Server Message Block (SMB).
Permite la interconexión de redes Microsoft Windows®, Linux, UNIX y otros sistemas operativos
juntos, permitiendo el acceso a archivos basados en Windows y compartir impresoras. El uso de
Samba de SMB lo hace parecer como un servidor Windows a clientes Windows.

Características de Samba

Samba es una implementación libre del protocolo de archivos compartidos de Microsoft Windows
(antiguamente llamado SMB, renombrado recientemente a CIFS) para sistemas de tipo UNIX. De
esta forma, es posible que computadoras con GNU/Linux, Mac OS X o Unix en general se vean
como servidores o actúen como clientes en redes de Windows. Samba también permite validar
usuarios haciendo de Controlador Principal de Dominio (PDC), como miembro de dominio e
incluso como un dominio Active Directory para redes basadas en Windows; aparte de ser capaz de
servir colas de impresión, directorios compartidos y autentificar con su propio archivo de usuarios.

Samba es una aplicación de servidor poderosa y versátil. Hasta los administradores bien
empapados deben conocer sus habilidades y limitaciones antes de intentar una instalación y
configuración.

Lo que Samba puede hacer:

Sirve árboles de directorios e impresoras a clientes Linux, UNIX y Windows

Asiste en la navegación de la red (con o sin NetBIOS)

Autentifica las conexiones a dominios Windows

Proporciona resolución de nombres de Windows Internet Name Service (WINS)

Actúa como un Controlador de Dominio Primario (Primary Domain Controller, PDC) estilo
Windows NT®

Actúa como un Backup Domain Controller (BDC) para un PDC basado en Samba

Actúa como un miembro servidor de dominio de Active Directory

Une un Windows NT/2000/2003 PDC

Lo que Samba no puede hacer:

Actúa como un BDC para un Windows PDC (y viceversa)

Actúa como un controlador de dominio de Active Directory

4.3 Servicio de repositorio de imágenes (clonado) y backup Servicio de

repositorio: SiSuite + PXE + TFTP Servicio de configuración de red: DHCP
Gestión de equipos cliente

pxe

Preboot eXecution Environment (PXE) (Entorno de ejecución de prearranque), es un entorno para

arrancar e instalar el sistema operativo en computadoras a través de una red, de manera
independiente de los dispositivos de almacenamiento de datos disponibles (como discos duros) o
de los sistemas operativos instalados.

PXE fue introducido como parte del framework Wired for Management por Intel y fue descrito en
la especificación (versión 2.1) publicada por Intel y Systemsoft el 20 de septiembre de 1999. PXE
utiliza varios protocolos de red como IP, UDP, DHCP y TFTP, y conceptos como Globally Unique
Identifier (GUID), Universally Unique Identifier (UUID) y Universal Network Device
Interface (UNDI).

El término cliente PXE sólo se refiere al papel que la máquina juega en el proceso de arranque
mediante PXE. Un cliente PXE puede ser un servidor, una computadora de mesa, portátil o
cualquier otra máquina que esté equipada con código de arranque PXE.

Funcionamiento
El firmware del cliente trata de encontrar un servicio de redirección PXE en la red para recabar
información sobre los servidores de arranque PXE disponibles. Tras analizar la respuesta, el
firmware solicitará al servidor de arranque apropiado el file path de un network bootstrap
program (NBP), lo descargará en la memoria RAM del computador mediante TFTP, probablemente
lo verificará, y finalmente lo ejecutará. Si se utiliza un único NBP para todos los clientes PXE se
puede especificar mediante BOOTP sin necesidad de un proxy DHCP, pero aún será necesario un
servidor TFTP.

Disponibilidad
PXE fue diseñado para funcionar sobre diferentes arquitecturas. La versión 2.1 de la especificación
asigna identificadores de arquitectura a seis tipos distintos de sistemas, incluyendo IA-64 y DEC
Alpha. Aunque la especificación sólo soporta completamente IA-32. Intel incluyó PXE en la EFI para
IA-64, creando un estándar de facto con esta implementación.

Protocolo
El protocolo PXE consiste en una combinación de los protocolos DHCP y TFTP con pequeñas
modificaciones en ambos. DHCP es utilizado para localizar el servidor de arranque apropiado, con
TFTP se descarga el programa inicial de bootstrap y archivos adicionales.

Para iniciar una sesión de arranque con PXE el firmware envía un paquete de tipo DHCPDISCOVER
extendido con algunas opciones específicas de PXE al puerto 67/UDP (puerto estándar del servicio
DHCP). Estas opciones indican que el firmware es capaz de manejar PXE, pero serán ignoradas por
los servidores DHCP estándar.

TFTP

TFTP (Trivial File Transfer Protocol). Es un protocolo de transferencia de ficheros asociado al

puerto 69 y basado en UDP que no proporciona ninguna seguridad. Por tanto en la mayoría de
sistemas es obligatorio que este servicio esté desactivado; su uso principal es el arranque de
estaciones diskless o de routers a través de la red, ya que la simpleza del protocolo permite
implementarlo en un chip, y sólo en ese caso se ofrece el servicio.

Si es este el caso, los ficheros que deseemos que sean públicos se han de situar en un determinado
directorio (dependiendo del clon de Unix, /tftpboot/, /etc/tftpboot/, /usr/local/boot/...) o utilizar
otros nombres de directorio como argumentos del demonio en /etc/inetd.conf, algo no
recomendable.

Algunos detalles del TFTP

 Utiliza UDP (en el puerto 69) como protocolo de transporte (a diferencia de FTPque utiliza
el puerto 21 TCP).
 No puede listar el contenido de los directorios.
 No existen mecanismos de autenticación o cifrado.
 Se utiliza para leer o escribir archivos de un servidor remoto.
 Soporta tres modos diferentes de transferencia, "netascii", "octet" y "mail", de los que los
dos primeros corresponden a los modos "ascii" e "imagen" (binario) del protocolo FTP.
Detalles de una sesión TFTP
Ya que TFTP utiliza UDP, no hay una definición formal de sesión, cliente y servidor, aunque se
considera servidor a aquel que abre el puerto 69 en modo UDP, y cliente a quien se conecta. Sin
embargo, cada archivo transferido vía TFTP constituye un intercambio independiente de paquetes,
y existe una relación cliente-servidor informal entre la máquina que inicia la comunicación y la que
responde.

La máquina A, que inicia la comunicación, envía un paquete RRQ (read request/petición de

lectura) o WRQ (write request/petición de escritura) a la máquina B, conteniendo el nombre del
archivo y el modo de transferencia.

B responde con un paquete ACK (acknowledgement/confirmación), que también sirve para

informar a A del puerto de la máquina B al que tendrá que enviar los paquetes restantes.

La máquina origen envía paquetes de datos numerados a la máquina destino, todos excepto el
último conteniendo 512 bytes de datos. La máquina destino responde con paquetes ACK
numerados para todos los paquetes de datos.

El paquete de datos final debe contener menos de 512 bytes de datos para indicar que es el
último. Si el tamaño del archivo transferido es un múltiplo exacto de 512 bytes, el origen envía un
paquete final que contiene 0 bytes de datos.

DHCP

El protocolo de configuración dinámica de host (en inglés: Dynamic Host Configuration Protocol,

también conocido por sus siglas de DHCP) es un protocolo de red de
tipo cliente/servidor mediante el cual un servidor DHCP asigna dinámicamente una dirección IP y
otros parámetros de configuración de red a cada dispositivo en una red para que puedan
comunicarse con otras redes IP. Este servidor posee una lista de direcciones IP dinámicas y las va
asignando a los clientes conforme estas van quedando libres, sabiendo en todo momento quién ha
estado en posesión de esa IP, cuánto tiempo la ha tenido y a quién se la ha asignado después. 

4.4 Servicio seguro de correo electrónico:

 Servicio de correo: POSTFIX (SSL)

Postfix es un agente de transferencia de correo (MTA), una aplicación que se utiliza para enviar y
recibir correos electrónicos. Se puede configurar para que solo se pueda utilizar para enviar
correos electrónicos mediante una aplicación local.  Esto es útil en situaciones en las que necesita
enviar notificaciones por correo electrónico de sus aplicaciones de forma regular o, simplemente,
si tiene mucho tráfico saliente que un proveedor de servicios de correo electrónico externo no
permite.  También es una alternativa más ligera a la ejecución de un servidor SMTP completo que
mantiene la funcionalidad necesaria.
Siendo ya más objetivos, algunas de las virtudes de Postfix son:
Diseño modular (no es un único programa monolítico)

La seguridad ha sido un condicionante desde el comienzo de su diseño.

Lo mismo cabe decir del rendimiento (seguramente Sendmail no se diseñó pensando que algún día
habría sitios necesitaran procesar cientos de miles o millones de mensajes al día).

Soporte para las tecnologías más usadas hoy día: LDAP, Bases de datos (MySQL), autentificación
mediante SASL, LMTP, etc.

Estricto cumplimiento de los estándares de correo-e (hasta donde se puede sin dejar a media
Internet, que no los cumple, sin poder usar el correo-e).

Soporte muy bueno para dominios virtuales.

Facilidad de configuración.

Compatibilidad hacia/desde fuera con Sendmail (.forward, aliases,

suplanta mailq, newaliases, /usr/lib/sendmail con versiones equivalentes).

Abundante documentación, y de calidad.

Fácil integración con antivirus.

Uso sencillo de listas negras.

Soporta de forma nativa el formato de buzones Maildir original de qmail.

Tiene múltiples formas de obtener información de 'lo que está pasando' para resolver problemas o
simplemente, para aprender.

Se pueden lanzar varias instancias de Postfix en la misma máquina con distintas configuraciones,
usando cada una distintas direcciones IP, distintos puertos, etc.

Filtrado de cabeceras y cuerpos de mensajes por expresiones regulares.

Utilidades para varias cosas, como gestionar las colas de mensajes.

 IMAP (SSL) Servicio de cliente de correo

IMAP (Internet Message Access Protocol) es un sistema que permite que nuestro programa de
correo electrónico se conecte a nuestra cuenta de correo electrónico y visualice los mensajes allí
almacenados. Los correos permanecen en el servidor por lo que pueden ser visualizados desde
otros dispositivos y programas.

Internet Message Access Protocol (IMAP), en su versión actual IMAP4, es el protocolo más

sofisticado. Les permite a los usuarios agrupar los mensajes relacionados y guardarlos en folders,
los cuales luego pueden ser organizador jerárquicamente. También tiene marcadores en los
mensajes que nos indican cuando un correo ha sido leído, borrado o reenviado. Además de que les
permite a los usuarios realizar búsquedas en su buzón.

Así es como generalmente funciona el protocolo IMAP:

Se conecta al servidor de correo en el puerto 143 (o 993 en el caso de conexiones SSL/TLS).

Recupera el mensaje de correo electrónico.

Se mantiene conectado hasta que la aplicación del cliente de correo cierre y descargue los
mensajes deseados.

Cómo mencione anteriormente, en este caso los mensajes no son eliminados del servidor, lo cual
tiene mayores implicaciones.

 web: Webmail (Apache2)

El webmail es un sistema de acceso al correo electrónico que permite acceder a sus
mensajes mediante un navegador web, sin tener que descargar los correos a su computador
personal mediante programas como Outlook, Eudora, incredimail etc.

Se provee una interfaz web por la que accede al correo electrónico, el webmail permite listar,
desplegar y borrar vía un navegador web los correos almacenados en el servidor remoto. Los
correos pueden ser consultados posteriormente desde otro computador conectado a la misma red
(por ejemplo Internet) y que disponga de un navegador web.

Apache es un servidor web HTTP de código abierto para plataformas Unix-like (BSD, GNU/Linux,
etc.), Windows, Macintosh y otras, que implementa el protocolo HTTP/1.1 y la noción de sitio
virtual. En sus inicios se basaba en el código de NCSA HTTPd 1.3, pero más tarde fue reescrito por
completo.

Bloque 5: Administración avanzada de

sistemas III: Clustering

5.1 Entornos de “alta disponibilidad” Sistema HA Linux:Balanceador de

carga HAproxy, alta disponibilidad con Hearbeat Implantación de un
sistema distribuido “mirror” en red de dispositivos de bloques: DRBD
Sistema HA LInux

High-Availability Linux (también denominado Linux-HA) ofrece funciones de migración tras error

desde un host de IBM® Netezza primario o activo a un host de Netezza secundario o en espera. El
daemon principal de gestión de clúster de la solución Linux-HA se denomina Heartbeat. Heartbeat
supervisa los hosts y gestiona la comunicación y las comprobaciones de estado de lo servicios.

Cada servicio es un recurso. Netezza agrupa los servicios específicos de Netezza en el grupo de

recursos nps. Cuando Heartbeat detecta problemas que implican un problema de error del host o
una pérdida del servicio para los usuarios de Netezza, Heartbeat puede iniciar una migración tras
error en el host en espera. Para obtener más detalles sobre Linux-HA y sus términos y
operaciones, consulte la documentación en http://www.linux-ha.org.

HAproxy

HAProxy, que significa High Availability Proxy (Proxy de alta disponibilidad), es un popular software

de código abierto TCP/HTTP Balanceador de carga y una solución de proxy que se puede ejecutar
en Linux, Solaris y FreeBSD. Su uso más común es mejorar el rendimiento y la confiabilidad de un
entorno de servidor distribuyendo la carga de trabajo entre múltiples servidores (por ejemplo,
web, aplicación, base de datos). Se utiliza en muchos entornos de alto perfil, incluidos: GitHub,
Imgur, Instagram y Twitter.

En esta guía, proporcionaremos una descripción general de qué es HAProxy, la terminología básica
de balanceador de carga y ejemplos de cómo se puede usar para mejorar el rendimiento y la
confiabilidad de tu propio entorno de servidor.

Terminología de HAProxy
Hay muchos términos y conceptos que son importantes cuando se analiza el balanceo de carga y el
proxy. Repasaremos los términos de uso común en las siguientes subsecciones.

Antes de entrar en los tipos básicos de balanceo de carga, hablaremos sobre las ACL, los backends
y los frontends.

Lista de control de acceso (ACL)

En relación con el balanceo de carga, las ACL se utilizan para probar alguna condición y realizar una
acción (por ejemplo, seleccionar un servidor o bloquear una solicitud) según el resultado de la
prueba. El uso de las ACL permite el reenvío flexible del tráfico de red en función de una variedad
de factores, como la coincidencia de patrones y el número de conexiones a un servidor, por
ejemplo.

Ejemplo de una ACL:

Esta ACL comprueba si coincide la ruta de la solicitud de un usuario que inicia con /blog. Esto
coincidiría con una solicitud de http://yourdomain.com/blog/blog-entry-1, por ejemplo.
Backend
Un backend es un conjunto de servidores que recibe solicitudes reenviadas. Los backends se
definen en la sección de back-end de la configuración de HAProxy. En su forma más básica, un
backend se puede definir por:

 qué algoritmo de equilibrio de carga utilizar

 una lista de servidores y puertos

Un backend puede contener uno o varios servidores; en general, agregar más servidores a tu
backend aumentará tu capacidad de carga potencial al distribuir la carga entre varios
servidores. Aumentar la confiabilidad también se logra de esta manera, en caso de que algunos de
tus servidores back-end no estén disponibles.

Heartbeat 

Clustering Alta disponibilidad en Linux. heartbeat

es un Servicio(Demonio (informática)) que proporciona funcionalidad de infraestructura de clúster

(comunicación y pertenencia) a sus clientes.

Esto permite a los clientes tener conocimiento de la ejecución, o no ejecución de los procesos en
otras máquinas e intercambiar fácilmente mensajes entre ellos.

Para resultar útil a los usuarios el dominio HEARTBEAT necesita emplearse en combinación con un
gestor de recursos del clúster (cluster resource manager - CRM)) el cual posee la tarea de iniciar y
parar los servicios (direcciones IP, servidores web, etc.) a los cuales el clúster aportará alta
disponibilidad. Pacemaker es el gestor de recursos de clúster preferido para los clústeres basados
en Heartbeat. Una característica primordial es que puede configurarse para trabajar de forma
pasiva y/o activa.1Otra característica de Heartbeat es poder trabajar con tantos nodos como se
requiera.

En los tiempos que vivimos es vital para las empresas y el negocio  tener los aplicativos, servicios y
páginas web disponibles siempre o casi casi siempre, y no sólo hablamos por el tema económico, si
no por imagen, pensad que si a la hora de intentar acceder a una página web determinada un alto
% de las veces no está disponible en términos profesionales da cierta inseguridad de cómo
manejan sus aplicativos, y en otros términos perderemos un considerable número de visitas e
interés por los usuarios.

Si hay un campo en donde Linux he visto que ha destacado o es el jugador titular indiscutible, es

en el clustering, la capacidad de unir varias máquinas virtuales o físicas para dar servicio a la vez
de forma que se balancean recursos para evitar sobrecargas de algunos servidores y en casos de
que alguno falle y no pueda darlo. Esto es algo transparente al usuario final, pues tendremos una
dirección virtual en donde se accede a todo el servicio del cluster y luego los nodos que son los
que realmente proporcionarán el servicio.

DRBD
Distributed Replicated Block Device (DRBD) es una unidad de dispositivo de bloque que duplica el
contenido de los dispositivos de bloque (discos duros, particiones y volúmenes lógicos) entre los
hosts. Netezza utiliza la duplicación DRBD solo en las particiones /nz y /export/home. A medida
que se escriben los datos nuevos en la partición /nz y la partición /export/home en el host
primario, el software de DRBD realiza automáticamente algunos cambios en la
partición /nz y /export/home del host en espera.

Habitualmente, esta partición de la que se hace mirror, solamente está montada en una de las
máquinas porque se utiliza un sistema de ficheros tradicional: ext3, raiserfs, xfs, … De esta forma,
solo una de las máquinas puede acceder a los datos, la que tiene la partición montada. Sirve para
montar un sistema de cluster en modo activo/pasivo, y que una de las máquinas tenga todos los
datos hasta que falle, y en ese momento se puede acceder desde la otra máquina.

Pero también se puede configurar para que ambas máquinas tengan acceso a la partición en
espejo, y en este caso habría que montar un sistema de ficheros para acceso en clúster,
como GFS o OCFS. De esta forma podemos montar un clúster activo/activo donde ambas
máquinas tienen acceso simultáneo al recurso de datos.

5.2 Entornos de cálculo y “alto rendimiento” Servicio (sistema) de

gestión de trabajos por colas: Open Grid Scheduler/Grid Engine

Open Grid Scheduler / Grid Engine es un sistema de colas por lotes de código abierto compatible
comercialmente para la gestión de recursos distribuidos. OGS / GE se basa en Sun Grid Engine y es
mantenido por el mismo grupo de desarrolladores externos (es decir, no Sun) que comenzaron a
contribuir con código desde 2001.

Por poseer la característica de ser de código abierto y gratuito está destinado para ser utilizado en
la página web del proyecto bajo la licencia del estándar de la industria Sun (Sun Industry Standards
Source License). Oracle proporciona una versión comercial, destinada a otros usos, disponible para
su adquisición en su página web. A pesar de esta situación, parece ser que a partir de la versión
6.2u6 todas las versiones posteriores que se vayan distribuyendo serán para uso comercial, siendo
gratuitas únicamente durante un periodo de prueba de 90 días a partir de adquisición.
SGE se usa normalmente en aquellos lugares que disponen de un gran número de ordenadores o
de clústeres de Computación de alto rendimiento (HPC). En estas estructuras, el SGE se encarga
principalmente de funciones como la aceptación, programación, envío y gestión de la ejecución
remota y distribuida de un gran número de tareas en el espacio de usuario, ya sean estas
secuenciales, paralelas o interactivas. Además de las funcionalidades ya mencionadas de SGE,
existe la posibilidad de gestionar y programar la reserva de recursos distribuidos en toda la
estructura, como procesadores, memoria, espacio de disco y licencias de software.