Ataque tipo: Man in the middle

A pesar de que existen herramientas específicas usadas por los pentesters y auditores de seguridad (además de terceros con peores intenciones…) para realizar este tipo de operaciones, vamos a enfocar el proceso paso a paso con el fin de entenderlo y poder atajar sus efectos.

Herramientas como Cain, Nemesis o Ettercap hacen este tipo de procesos/ataques a las mil maravillas, con variantes e ingredientes añadidos, pero la base de un MITM (Man In The Middle), pasa por entender lo que ocurre cuando enviamos algo a otro sistema informático.

Normalmente, las personas retenemos mal una secuencia de números de cierto número de cifras pero nos es mucho mas fácil de retener una secuencia de letras porque le vemos mas sentido.

Por ello los dominios tienen nombres como:  google.com

Esta cadena de caracteres (“google.com”), nos resulta mas amigable que un  74.125.230.81

Ese conjunto de números es lo que denominamos IP y todos ya tenemos en nuestro vocabulario común. Más concretamente una IPv4 consistente en 32 bits agrupadas en 4 grupos de un byte cada uno (1 byte=8 bits), de ahí los puntos entre los números. Dado que este tipo de información es tan básico dejaremos que quien precise mas información sobre IPs vaya aquí.

El caso es que cuando introducimos una dirección como “www.google.com” en un programa, el ordenador no tiene la mas remota idea de donde está esa web, equipo, servicio o lo que quiera ser esa cadena de caracteres.

Por ello “pregunta” a otros ordenadores, denominados servidores DNS ago como (entiendase conversación entre ordenadores :-D):

Tu equipo: ” –¿Sabría usted decirme la IP de esta cadena que me ha pedido el usuario?

El servidor DNS: “-Si claro, como no… vaya a la dirección 74.125.230.81 y olvidese de lo que su usuario le ha pedido. Comprobara que pese a esto, su usuario se siente satifecho con lo que usted le ofrece…(porque es lo mismo)

La cosa es que el equipo “va” a la dirección IP y no al nombre que el usuario ha pedido, porque si bien son lo mismo, podemos decir que el texto es la forma en la que se refieren los usuarios a un determinado sitio/equipo/web/servicio, mientras que los números (IP), es la forma de denominarlo que tienen los ordenadores…

Ahora la pregunta es:

¿Y que ocuriría si el servidor DNS al que preguntas…resulta ser un suplantador del original?

Podría dirigir cualquiera de las peticiones que el usuario efectúa, hacia cualquier otro lugar…

Ese suplantador, es uno de tantos tipos de man in the middle, si bien veremos otros tipos de forma mas profunda.

Este ataque es de fácil realización por várias técnicas, si bien la de modificar la configuracíón del router de acceso a internet del usuario o cambiar las DNSs de su equipo son las mas fáciles y utilizadas.

Sigamos profundizando algo más en la comunicación entre equipos.

Hemos visto que las cadenas de caracteres se transforman en IPs, pero hay pasos adicionales.

Veámoslo con ejemplos.

Si utilizas MS Windows (si usas Linux y no sabes que es una shell…mal lo llevamos…), pulsas inicio, ejecutar y tecleas “cmd” (+ enter), para abrir una de esas consolas negras “que no sirven para nada porque no tienen iconos…:-)”

Si en dicha consola (a la que denominaremos “shell”), tecleas hostname y verás el nombre de tu equipo y si introduces el comando “ipconfig” (ifconfig en Linux), verás la dirección IP de tu ordenador.

Pero hay más…

Si hacemos un ping (simplificando: comando para comprobar que el destinatario responde) a tu propia ip, comprobarás que responde a la petición.

Podríamos decir que la dirección IP es otro número “impuesto” al equipo (como el número de la seguridad social, o del carnét de conducir), si bien no es propio del equipo por construcción.

Hay otro número (hablando en binario), que SI que es intrinseco al equipo y que viene en su “ADN”, pues se le otorga durante su contrucción y se supone único a nivel mundial… “:-/”

A este número se le denomina dirección MAC o dirección física y cada tarjeta de red tiene uno diferente.

Una vez que un ordenador sabe a que IP debe enviar su mensage/peticion/lo que sea…dentro de una LAN (red local) pregunta a dicho equipo por su dirección MAC.

Tu ordenador:  “-Oye 192.168.1.23, te importa darme tu dirección física para enviarte los datos?, por cierto, la mía la tienes en mi propia petición

El otro equipo/router/aparato: “-Si claro, mi MAC es esta: 00:1E:0B:00:2F:3C

La representación se suele realizar en formato hexadecimal, ya que es mas corto que el mismo número en binario que sería este:

1111000001011000000000010111100111100

Que a su vez corresponde a este otro en decimal (formato numérico al que mas acostumbrado el está la mayoria de NO informáticos…)

129033580348

Así como el protocolo para resolver una IP, en base a una FQDN (Full Qualified Domain Name) como http://www.google.com, el algoritmo utilizado era DNS… existe otro algoritmo utilizado para resolver direcciones MAC en base a una dirección IP: Se denomina ARP (Address Resolution Protocol).

E xiste una forma de ver las direcciones MAC que un ordenador tiene en cache, o dicho de otro modo, las ultimas y mas habituales a las que ha contactado durante los ultimos instantes. El comando es “arp -a“. Con dicho comando veremos una lista de equivalencias entre IPs y MACs, que usa el equipo para no tener que resolver direcciones que ya haresuelto hace poco tiempo (segundos/minutos dependiendo de configuraciones).

Cualquier trama que un equipo envía, incluye la dirección MAC de éste (así como su IP), y por tanto un simple ping a la IP de un equipo, desencadena la resolución de su dirección física (a no ser que la tengamos ya en memoria, por una transmisión reciente anterior).

Ahora bien, el ataque del que hablamos, se cimenta en este mecanismo de resolución.

Supongamos que desde tu equipo estás conectado a internet mediante un router. Ello implica que tanto router como tu equipo tienen la IP y MAC del otro y de ese modo transmiten datos entre ambos (y tambien al resto del mundo).

Como sabemos, todo lo que se envía, se pasa en un momento u otro a binario (ceros y unos), y por tanto entre ese conjunto de ceros y unos debe estar incluida la información de la IP, la MAC y otros datos. Si sabemos exactamente donde y conseguimos realizar un falseado de los mismos…tendremos desencadenado el ataque y conseguiremos “ver” todo el tráfico que intercambien los equipos atacados (en este caso un equipo y su router de internet).

El esquema quedaría de este modo:

Veamos el proceso paso a paso:

1.- Cuando el equipo víctima y el router, quieren comunicar entre si,  intercambian sus ips y direcciones MAC por medio de ARP

2.- Este mecanismo se realiza de vez en cuando para refrescar la información.

3.- El atacante consigue la ip y la mac de ambos (equipo victima y router), por medio de un simple ping a cada uno( u otro mecanismo cualquiera).

4.- Falsea la información de ambos equipos (equipo víctima y router) y ellos mismos empiezan a mandarle la información “creyendo” que
lo hacen a su legítimo interlocutor.

Ahora vamos a la práctica:

El atacante hace un simple ping a los equipos víctima:

Además captura una trama para modificarla:

Esta trama, almacenada en formato “pcap”, puede almacenarse en un fichero y modificarse con un editor hexadecimal.

El atacante creará dos tramas “envenenadas”.

En la trama que , el atacante, mandará al router, cambia la mac del equipo víctima por la suya,( manteniendo la ip del equipo víctima). De este modo cada vez que el router quiera mandar datos al equipo víctima, realmente la mandará a laMAC del atacante y este observará todo el tráfico.

En la trama que enviará al equipo víctima, cambiará la MAC del router por la suya propia, para que el tráfico generado por la víctima y con destino al router, realmente vaya a parar al atacante.

Posteriormente, solo tiene que crear un pequeño script que envíe cada pocos segundos estas tramas a ambas víctimas (equipo y router), porque sino en unos segundos, ellos mismos, mandarán los datos correctos al otro y el ataque cesará. Este envío contínuo de datos manipulados es lo que llamamos envenenamiento por ARP (ARP Spoofing o ARP Poisoning).  (para los mas curiosos:el programita “file2cable”, permitirá mandar por la red el contenido de los archivos manipulados como tramas).

La víctima ahora está a merced del atacante que puede ver todo el contenido de sus transmisiones con el router así como cortarlas, almacenarlas, modificarlas antes de que lleguen a su legítimo destino, reenviarlas…

Como contramedidas o forma de protegerse de este tipo de ataque, hay programas y software de seguridad que permite bloquear o avisar ante cambios de direcciones MAC. Hay quienes optan por tener fijas ciertas direcciones como las del router, evitando su cambio sin autorización. Hay varias formas de evitar este tipo de ataques, pero lo primero para ello, es conocer como se efectúa y como consecuencia entender que elementos deben ser vigilados en una red.


9 enero 2011 at 18:22 1 comentario

Refrigeración del centro de datos: ahorrando con conciencia ecológica

Ya son varias las veces al entrar en un centro de datos, me ha sorprendido comprobar como el sistema de “aire acondicionado”, es EL sistema de refrigeración permanente (nótese en determinate EL y no UN…), en configuraciones diversas N, 2N 2N+1…y variantes…

Hay responsables que comentan:

– “Al ser inverter no tenemos picos de consumo y la potencia consumida es proporcional al esfuerzo que se le pide al sistema”. Si bien es cierto, un sistema de apoyo como el que describiré consume Y TIENE UN MANTENIMIENTO DECENAS DE VECES INFERIOR.

Algunos pensarán que hablo de lugares concretos y proyectados con medios escasos pero he visto dicha configuración desde centros privados a algunos de instituciones públicas y cada cual de distínto tamaño y uso.

Hay que tener en cuenta que el coste de la refrigeración de un CPD es muy alto, llegando a ser el 50% de la potencia invertida en el hardware, con lo que cualquier ahorro supone una gran optimización de costes y rendmiento (así como una menor huella ecológica y lo que ello conlleva).

Una de las formas mas prácticas consiste en acondicionar un plenum superior o chimenea natural de la suficiente altura que provoque una aspiración natural del aire caliente y ello reduzca las necesidade de extracción del mismo.

Dado que no siempre se puede disfrutar de este elemento (dependiente de la construcción del edificio), se puede optar por apoyar los sistemas de aire acondicionado con otros de aire forzado desde el exterior.

Mediante cabinas en las que se incorporan ventiladores específicos para este cometido, se toma aire del exterior y se insufla a los pasillos fríos.

Dado que la gran mayoría de noches del año la temperatura es bastante inferior  a la de cualquier centro de datos y lo mismo ocurre durante todo el invierno y parte de primavera y otoño… con un correcto dimensionamiento podremos prescindir del sistema de aire acondicionado durante gran parte del año.

Será necesario incorporar diversos sistemas sin gran complicación compuestos en su versión mas sencilla por automatismos gobernados por higrómetros y termostatos de modo que en función de temperatura y humedad se regule la velocidad de los motores de los ventiladores para un consumo menor siempre que sea posible.En versiones mas avanzadas se podrá incorporar control mediante sistemas informáticos, aunque no siempre es necesario.

En cuanto a la regulación de la velocidad, depende de si estos (lo motores de los ventiladores) son trifásicos o monofásicos.

(Se pueden colocar monofásicos haciendo una correcta distribución de la carga entre las fases, lo que a veces puede ser una ventaja)

En el primer caso casi estaremos obligados a incorporar reguladores de frecuencia que modifiquen la velocidad, pero en caso de ser monofásicos, podemos decantar la decisión por reguladores de tensión, mas económicos y de igual resultado.

De este modo el consumo eléctrico del sistema de aire forzado puede llegar a ser hasta un 90% menor al del sistema de aire acondicionado y de uso durante una gran parte del año. En otra buena parte el aire podrá funcionar a una potencia menor siendo apoyado por el sistema descrito.

En función de ciertas combinaciones de datos podemos hacer que el sistema actúe únicamente sobre el sistema de aire forzado, en combinación o solamente el sistema de frío (lease aire acondicionado).

Mejoras a esta metodología consisten en la incorporación de una estación meteorológica en el exterior y relojes horarios que permitan conocer con una previsión de horas la tendencia del tiempo y adelantar el funcionamiento del sistema esas horas cuando sea factible ahorrando otro buen puñado de watios consumidos.

Así mismo recordaré lo ya indicado en otros posts, en los que menciono la gran mejora existente en el consumo cuando se separa totalemente el pasillo frío del caliente.

Por medio de cortinas (usadas habitualmente en sistemas de cámaras industriales de frío), sistemas de metacrilato disponibles en varios fabricantes así como otras técnicas que no pemitan la mezcla de corrientes de aire calientes y frías.

Tapas en las zonas (“Us”) de los racks no utilizadas, así como en los laterales no cubiertos por cables, evitarán reflujos de aire hacia el pasillo frío que calienten el aire que se aporta a los elementos de hardware. Estos reflujos hacen que los sensores de temperatura de los elementos detencten mayor temperatura y por tanto aumenten la velocidad de los ventiladores. Consecuecia: mayor consumo y contamientación acústica del CPD.

El coste de la instalación de elementos e instalaciones descritas es fácilmente amortizable antes de los tres años desde su instalación , lo que demuestra el alto grado de optimización (con respecto al sistema de contar únicamente con sistemas de aire acondifionado).

27 octubre 2010 at 22:01 2 comentarios

Clusters HA: No solo para empresas con altos recursos económicos

Existen ciertos servicios que tienen que ser garantizados y por ello se designan recursos y medios que permitan obtener un tiempo de inactividad tendente a cero (o sea, una disponibilidad de casi el 100%, ya que la perfección es virtualmente imposible).

Deseamos disponer del servicio en todo momento incluso ante fallos de las comunicaciones o del hardware.

Para ello no hay una única receta y se aplican diversas técnicas que exceden el propósito de este artículo, si bien una útil y que debe ser valorada es la de la construcción de un Cluster HA (high availability cluster).

Un cluster de alta disponibilidad consiste en un mínimo de dos servidores (en adelante: nodos), que ofrecerán de forma conjunta el servicio en cuestión.

Estos servidores se verán como una única entidad (el cluster), que será la que ofrezca el servicio.

El modelo mas básico y sencillo de cluster es el Activo-Pasivo.

En este caso ambos servidores se conectan entre si, para que cada cual monitorice a su compañero, de tal modo que uno realiza el trabajo mientras el segundo queda a la espera, comprobando en todo momento que el nodo activo, realiza el trabajo. Si se da la circunstancia de caida del nodo que realiza el trabajo, el nodo pasivo toma el control y continua realizando el trabajo (pasando de este modo a ser el nodo activo). De cara al cliente/usuario del servicio, solo percibe que el servicio continua ofreciéndose sin tener que ser partícipe del problema o fallo que se ha producido en los equipos que ofrecen el citado servicio.

Normalmente las empresas disponen de redes SAN, que utilizan para ofrecer una o varias LUNs, que permiten que ambos nodos del cluster dispongan de un lugar de datos accesibles por ambos.

Pongamos un ejemplo sencillo:

Supongamos que queremos que nuestro servicio de alta disponibilidad sea un servidor web mediante apache.

El servicio apache, utiliza (como cualquier aplicación), unos archivos de configuración y un lugar donde residen las páginas que servirá a los clientes que conecten a nuestra web.

Si ambos nodos deben poder ofrecer la web, lo mas lógico es que tanto la configuración como las webs estén en uno/varios (olvidemos en este caso la seguridad) contenedores accesibles por ambos nodos.

De este modo cuando uno de los nodos ponga en marcha apache, utilizará la configuración residente en un punto compartido, y por tanto la misma que su compañero. De igual modo las páginas y otros elementos que compongan el site, también podrán ser cargados.

El esquema sería el siguiente:

 

Ambos nodos del cluster disponen de acceso a almacenamiento compartido

 

En caso de no disponer de una infraestructura como la mencionada, no todo está perdido. Existen soluciones gratuitas que permiten crear esta base sin costosos elementos como los antes mencionados.

Este es el caso de DRBD, que permite, configurar una partición o disco de DISCO LOCAL de cada nodo de modo que el disco/partición seleccionada para este uso forma parte de una especie de RAID 1 vía ethernet . Dicho de otro modo, cualquier cosa que se escriba en una de las particiones que forman el recurso compartido por drbd, será replicada en la partición/disco residente en el otro nodo y viceversa.

Con este sistema y ante la caída del nodo activo, dispondremos de la información común replicada en el nodo pasivo y por tanto en condiciones de tomar el control. Este sistema tiene 3 posibles modos de réplica (A,B,y C), de los que por seguridad lo mas recomendable es utilizar el C, si bien la configuración del módulo “drbd”, no es objeto actual del artículo, creo importante citar este aspecto ya que una mala elección del modo de réplica puede dar al traste con la información compartida del cluster.

La configuración de DRBD es sencilla y en la web del proyecto hay buena documentación y ejemplos de configuración.

Una vez solventado el mayor problema para montar un cluster HA, sin almacenamiento compartido, sigamos examinando el resto de claves para la realización del cluster.

Los nodos deben estar permanentemente conectados para monitorizarse entre si. Para ello es mas que recomendable utilizar varios medios de modo que la rotura de uno de los enlaces no suponga un problema.

Lo mas económico pasa por la utilización de una tarjeta de red exclusiva para este cometido y ofrecer redudancia de comunicación mediante el puerto serie de los equipos. Partiendo de que la información para la monitorización es poca, la velocidad que ofrece el puerto serie no es ningú problema. Evítese el uso de switches para la unión vía ethernet, siendo la mejor opción un cable cruzado y directo entre las tarjetas de red destinadas a la monitorización. Del mismo modo procederemos entre los puertos serie con el cable apropiado.

Es importante tener e cuenta que el nodo pasivo, en caso de no recibir, señal desde el nodo activo, se pondrá en acción pasando a ser el nodo activo. Aqui surge un problema, ya que podría darse el caso de que el nodo pasivo no reciba el heartbeat del nodo activo por un problema en el propio nodo pasivo (pod´ria averiarse su tarjeta de red y puerto serie por los que transmite el heartbeat…). Si se dá este caso, ambos nodos se pondrían en funcionamiento de forma simultánea con las consecuencias que esto tendría (las mencionaré posteiormente). Para evitar esto, una forma sencilla de averiguar el origen del problema pasa por lo siguiente:

Se pueden configurar los nodos de modo que ante la pérdida de señal por parte del nodo opuesto, el nodo pasivo, compruebe si el problema es suyo por medio de un ping a un elemento externo al cluster que siempre esté encendido (un router, la ip de gestión de un switch o similares). Si el nodo pasivo puede comunicar con el elemento externo al cluster y no con su compañero, el problema probablemente esté en su compañero, mientras que de ser imposible la comunicacion con otros elementos, probablemente el problema sea de él mismo y por tanto NO activase como nodo activo (ya que probablemente el nodo actualmente activo está funcionando correctamente).

La información de monitorización se conoce como heartbeat (latido), consistente en su forma mas básica en la emisión de un ping desde uno de los nodos, que debe ser respondido por el otro integrante del cluster en caso de estár “vivo”.

No es recomendable compartir una tarjeta de red para este y otros usos ya qua la saturación de la misma en un momento dado, podría dar a entender a uno de los nodos del lcuster que el otro no responde por algún fallo. Otras posibilidades pasan por transmitir una frase cifrada que ambos nodos conocen y que aumenta laseguridad del sistema (un atacante con acceso al canal de heartbeat podría hacer pasar un falso ping por el del otro nodo y comprometer todo el sistema).

La siguiente clave consiste en ofertar el servicio vía red mediante la misma IP en todo momento e independientemente del nodo que esté activo en cada instante.

El segundo y vital componente de nuestro cluster será el software heartbeat .

Este software es, en si, el alma del cluster y mediante una fácil configuración consistente en 3 archivos, podemos indicarle:

  • IP de servicio (que ip será la que ofrezca el servicio y por tanto ésta se configurará de forma automática en el nodo activo en cada momento. Esta IP no debemos configurarla de forma manual en ninguna tarjeta de red, ya que el software lo hará por nosotros)
  • Servicio a clusterizar (en nuestro ejemplo apache)
  • Forma de comunicación y heartbeat a utilizar, canales de transmisión (ethernet + pto. serie en el ejemplo)

Con este software instalado y configurado en ambos nodos del cluster solo tendremos que arancarlo como un servicio mas para que automáticamente tengamos el clustern en funcionamiento.

Aspectos a cuidar y tener en cuenta son aquellos que puedar dar al traste con el sistema. De estos quiero hacer especial mención a aquellos que pueden hacer que ambos nodos del cluster se dispongan simultáneamente como nodo activo.

Esto puede ser desastroso, por múltiples factores de los que los mas importantes y fáciles de ver serían:

  • Ambos nodos intentarán configurar la misma IP con los conflictos que esto ocasionará
  • Ambos nodos querran poder escribir sobre el contenido compartido pudiendo corromperlo

Es por ello que existen elementos hardware que se aseguran de que solamente un nodo esté activo en el mismo instante de tiempo. El problema reside en que nuestro artículo versa sobre clusters para empresas con bajos o casi nulos recursos económicos y por tanto tenemos que sacar de la chistera otro componente de software llamado watchdog.

Watchdog, es un software que se instala en cada nodo y que “automonitoriza” ese nodo.

Si el servicio clusterizado se queda colgado o tiene problemas de servicio, watchdog, reinicia el nodo, haciendo que ya no esté disponible y por tanto el nodo pasivo, puede tomar el control con seguridad. Cuando el nodo activo, vuelve a arrancar, y dependiendo de la configuraión deseada, podrá ser el nuevo nodo pasivo (hasta que su compañero caiga por alguna razón), o volver a notificar al nodo activo que él será el que pase a serlo y requiriendo que su compañero vuelva a hacer las funciones de nodo pasivo.

9 octubre 2010 at 10:50 Deja un comentario

Gestión & Sellado de LOGs

El volumen de datos que se  “mueve” en un centro de datos, a lo largo de una jornada es ingente.

Es por ello, que la atención del personal se centra en ciertos parámetros, mientras que otros se supeditan a la activación de alguna alarma (cuando se sobrepasa/disminuye cierto límite en un valor como cantidad de datos transferidos por segundo, ancho de banda libre, consumo de CPU, temperatura, velocidad de giro de un ventilador o estadísticas de I/O de un determinado disco).

Toda la información del entorno debe ser almacenada aun cuando no salten alarmas a fin de su posterior uso en análisis de funcionamientos, tendencias, investigación de eventualidades o colaborar con la justicia si así se  requiere.

La forma de almacenamiento de los datos suele consistir en ficheros de texto (encriptados o no), en los que se va almacenando la información. De cada evento almacenado se deberá de almacenar fecha, hora, evento (y otro tipo de información variable como origen, servicio relacionado, prioridad, frecuencia de la ocurrencia, impacto…).

Cada cierto tiempo (diferente para cada Log  dependiendo de su naturaleza, pues los hay que crecen de forma desmesurada, mientras otros lo hacen a un ritmo mucho mas sosegado), lo correcto es realizar una rotación de estos Logs (hay sistemas para efectuar esta rotación de forma automatizada). Esto hará que podamos buscar la información en ficheros mas pequeños, delimitados entre fechas y con menor riesgo de corrupción de los mismos.

Una vez rotado un determinado LOG, dispondremos de un fichero “normalmente comprimido”, que contendrá la información de un determinado aspecto del entorno entre dos fechas concretas.

La pregunta que surge inmediatamente es: ¿Como saber que dicho LOG no ha sido modificado posteriormente a su rotado y compresión?

Supongamos que alguien comete un fallo en la gestión de la plataforma y en vez de comunicarlo, prefiere ocultar esta acción. Lógicamente precisará eliminar las entradas de log relacionadas con su acción.  Para evitar problemas es mejor adoptar medidas que aporten un mayor nivel de seguridad en estos LOGs.

Una forma útil, con soporte jurídico ante posibles usos legales de dichos datos/logs y sencillo de implantar consiste en firmar digitalmente dichos ficheros con un certificado digital que asegure que ante la modificación del log posteriormente a su firma, quede constancia de tal hecho.

La firma digital de cualquier tipo de fichero, permite asegurar que el fichero firmado, no ha sido modificado desde que se produjo la firma y por tanto que no ha sido falsificado o manipulado.

La firma puede realizarse mediante la emisión de un certificado desde una CA generada por nuestra empresa o por una externa.

Es importante saber que para ciertos  usos y dependiendo de la ley vigente en cada estado, puede requerirse que la firma se produzca o efectúe con certificados de determinadas CAs “de confianza para el estado” y con sellado de tiempo.

El sellado de tiempo consiste en la inclusión de la fecha y hora en la que se efectúa la firma digital, por medio de la petición de la misma a un
servidor
(y no la fecha y horas del equipo en el que se realiza la firma), normalmente aportado por la propia CA. Por tanto de ese modo no cabe falsificación “fácil”, por parte de quien firma los LOGs, en cuanto al momento en que realizó dicha operación.

Por supuesto estos procedimientos no quitan ni sustituyen al correcto almacenado de los Logs, ni a su correcta custodia, o herramientas adicionales que puedan utilizarse para mejorar su gestión, salvaguarda y replicación, pero es una forma válida y adicional de ofrecer una consistencia legal de los mismos así como una solución para la falsificación de estos datos.

30 junio 2010 at 9:54 Deja un comentario

Alimentación eléctrica: SAIs (UPS).

Ya lo dice la ley de la conservación de la energía: “La energía ni se crea ni se destruye, simplemente se transforma“.

El caso es que hay que transformarla  de la forma correcta…

Y para ello es necesario incorporar a la infraestructura, elementos que permitan ofrecer una correcta calidad de aporte eléctrico a los elementos del centro de datos, así como permitir el desempeño de la producción  incluso ante un eventual corte de suministro por parte de la compañía eléctrica de turno.

Estos elementos se denominan SAIs o UPSs (las primeras siglas en español;  las segundas en Inglés)

SAI: Sistema de alimentación ininterrumpida.

UPS: Uninterrumpible power supply.

Realmente hay bastantes tipos de SAI, pero de forma genérica, los describiremos como un conjunto de circuitos que estabilizan la corriente que nos aporta la compañía eléctrica y añaden como segundo componente, una o varias baterías.

Estas baterías se cargan con la propia energía que aporta la compañía suministradora, para que ante un corte, el sistema pase, de forma automática, a proporcionar la energía almacenada a los elementos (servidores, u otros aparatos) y que estos sigan funcionando sin percatarse del corte de suministro.

Hay un SAI para cada necesidad

Si hacemos una clasificación  en función de su diseño, podemos encontrar estos tipos de SAI:

  • Standby
  • Interactivo
  • On-line de doble conversión
  • On-line de doble conversión mejorados

Standby: El mas económico (a usar con ordenadores personales en todo caso). Digamos que ante un corte, se activa un interruptor que hace que la alimentación pase a realziarse desde la batería. Un problema de este tipo de sistema es que durante el cambio, se pueden producir (de hecho se producen) desde arcos voltáicos mientras el interruptor aun está en movimiento, hasta picos de corriente originados por la acción de la carga sobre la fuente de alimentación.

Esquema de bloques de un SAI de tipo StandBy

Interactivo: En este caso, no existe un interruptor, sino que el inversor (convertido de corriente contínua a alterna y viceversa), siempre está conectado a la salida del SAI, lo que hace que ante un corete de suministro, lo elementos alimentados por el SAI, no aprecien picos derivados del propio funcionamiento del SAI. Este tipo de SAI, es el mas utilizado en Pymes para proteger servidores departamentales. así mismo, la calidad de señal que proveen suele ser mejor que en los de tipo standby y disponen de mejor circuitería de filtrado, lo que los situa claramente en una gama superior.

Esquema de bloques de un SAI de tipo Interactivo

Online de doble conversión: Normalmente reservado a SAIs de cierta potencia, gama, calidad (y precio). La gran ventaja de este tipo de sistema, estriba en que la alimentación de las cargas (carga: equipo alimentado por el SAI, como por ejemplo un servidor) siempre se produce desde un coversor/inversor que por construcción no depende de la entrada (sino de un segundo inversor). Esto provoca que un corte de suministro en la entrada del SAI, no se aprecia en las cargas. Además como la alimentación de todo el sistema (cargas y la propia batería del SAI), se producen por medio de un segundo inversor/conversor, la calidad de filtrado de la corriente es superior ya que se produce por duplicado.

Hay que señalar sobre este tipo de SAI, que produce una salida eléctrica casi perfecta (tanto en calidad como en forma de honda), pero tiene algúnos problemas derivados así mismo de su propia concepción. El principal problema reside en el contínuo desgaste de los componentes eléctricos (lo que disminuye su vida útil), y requiere que los generadores /grupos electrógenos esten preparados para trabajar con este tipo de SAIs.

Esquema de bloques de un SAI online de doble conversión

On-line de doble conversión mejorados: Para mitigar los problemas originados por el sistema de doble conversión online, los diferentes fabricantes han propuesto e implementado mejoras, como el incluir un transformador+ un regulador de corriente entre la entrada y el primer conversión/inversor, lo que demuestra una mejora ostensible en los efectos provocados por el SAI. Otros fabricantes han optado por agregar un cirtuito de retroalimentación desde el segundo inversor al primero y si bien esto no se ha demostrado que ofrezca los resultados esperados, mitiga en cierta medida algunos efectos.

En cualquier caso, y a modo de resumen, el SAI debería de ser una de esas piezas del puzzle imprescindibles y de cuidada elección ya que toda nuestra infraestructura dependerá de su correcto funcionamiento.

7 junio 2010 at 13:39 Deja un comentario

Descubriendo la nueva IBM System Storage DS3500

IBM lanza el 18 de Mayo su nueva apuesta en el mercado de almacenamiento, en el mercado de las cabinas para redes SAN.

Se trata del nuevo componente denominado DS3500 y por supuesto dispone de fuente redundante dual así como de 2 controladoras típicas de los sistemas destinados a ofrecer alta disponibilidad y redundancia total .

Empezaré enumerando sus características técnicas en cuanto a conectividad:

  • 3 posibles opciones a elegir: SAS, FC/SAS, iSCSI/SAS
  • 4 u 8 puertos  host a 6Gbps
  • 8 Gb puertos FC & 4 puertos  6Gbps SAS host
  • 8 puertos iSCSI a 1Gbps & 4 puertos  6Gbps SAS

En lo referente a escalabilidad,  indicar que admite hasta 96 unidades de disco:

  • SAS de alto rendimiento, nearline SAS y SED SAS
  • Admite expansión mediante dos posibles módulos en forma de bandejas
    • EXP3512  (formato 2U con discos de 3,5″)
    • EXP3524 (formato 2U con discos de 2,5″)
  • 2 drive  interfaces SAS 6Gbps
  • parte de 1 GB de cache ampliable a 2GB
  • Característica opcional “Rendimiento Turbo”

Además incluye, una serie de caracteríscitcas, hasta ahora reservadas a sistemas de las gamas mas altas como son la auto-encriptación total de disco nativa, mientras sigue aportando funcionalidades como Volume Copy (clonado en caliente de LUNs) así como Flash Copy (instantáneas de volumen a nivel de LUN), típicas de las serie DS3000.

Por otro lado sigue incorporando el sistema de particiones (hasta 64, frente a las 32 del resto de gama DS3000), que no son otra cosa que el número de grupos de acceso concurrentes a cabina por parte de los servidores a los que se sirven las LUNs.

Como característica adicional, admite remote mirroring mediante puertos host FC (8 por systema de almacenamiento).

Se lanza en dos posibles modelos cuya denominación será:

  • DS3512 (12 discos de 3,5″ por bandeja)
  • DS3524 (24 discos de 2,5″ por bandeja)

IBM pone a disposición del cliente una serie de tarjetas de expansión que permiten aumentar y ofrecer mayor conectividad tanto por número de puertos como por tipología de los mismos (SAS, FC o iSCSI), lo que eventualmente permite incluso reconvertir toda una red SAN de un protocolo a otro en función de necesidades y rendimiento necesarios.

De momento y a falta de mas información por parte del fabricante, se echa de menos la posibilidad de incluir discos SATA, como lo permite el resto de la gama DS3000 y mezclarlos en cualquier bandeja esto último es una limitación en otros fabricantes).

El procesador que gestiona la lógica de las controladoras es un Power PC 440 ROC 800-MHz al que tambien se le encomiendan las funcionas del cálculo XOR y de P+Q en caso de requerir  RAID6.

Como mejoras ostensibles frente al resto de la gama DS3000, y a modo resumen mencionaremos el paso de tecnología de 3Gbps SAS a la de 6Gbps. Mayores posibilidades de conectividad y flexibilidad en cofiguraciones, así como una mayor oferta de puertos (tambien en cuanto a su número, una vez decidida una determinada tecnología de acceso).

En el resto de la gama DS3000 contamos con una capacidad de hasta 48 drives (lease discos),mientras que aqui se nos ofrecen hasta 96, si bien en lo que respecta a volumen total, habrá que esperar a realizar un pequeño cálculo (por ejemplo un DS3400 admite hasta 48 discos SATA), una vez desvelados los tamaños máximos de disco tanto en 3,5 pulgadas como en 2,5.

Lógicamente en este caso, no se busca un sistema que compita, “a priori”, en volumen de almacenamiento,  con sus hermanas de gama, sino en la bússqueda de mayor número de IOPS, dado que admite un mayor número de discos y además de tipo SAS, lo que le permitirá entrar en entornos mas exigentes y hacer frente a mas de un sistema de gama teóricamente superior.

El sistema de gestión está basado en el mismo storage manager con el “nuevo”, interface  que el resto de gama estrenó hace un tiempo, si bien nos ha parecido que incorpora alguna funcionalidad propia del entorno de gestión de las gamas DS4000 y DS5000. Damos por supuesto que será compatible con el plugin para su integración con vCenter en entornos Vmware.

Como ya es típico en este tipo de productos de IBM, ofrece posibilidad de trabajar con RAID 0, 1, 0+1, 3, 5 y 6, discos en hot spare (a la espera para ser utilizados de forma automática, ante la rotura de otros discos asignados a determiando array) y reconfiguración  dinámica y en caliente a otros niveles de RAID (o dicho de otro modo, disponer de un array en raid 5 y migrarlo en caliente a otro nivel de RAID sin que los usuarios tengan que dejar de trabajar).

Ya mencionada anteriormente pero digna de mención es la inclusión de capacidad “Mirroring”, que permite migrar un volumen de un sistema de disco a otro (teóricamente incluso vía WAN, siempre que se cumplan ciertos parámetros), para replicar en caliente volúmenes enteros tanto de forma síncrona como asíncrona (característica propia de sistema de gama superior) en tre modos diferentes: Metro Mirror, Global Copy y  Global Mirror.

Con ello disponemos de mayores posibildiades  en cuanto a backup, replicación y explotación de datos.

Así IBM completa una gama que se consolida como referente en el mercado de gama A.

13 mayo 2010 at 0:24 2 comentarios

Rendimiento del Centro de datos & ecología

El consumo eléctrico de los centros de datos es cada vez mayor y ya disponemos de estudios que indican que los centros de datos consumen hoy en día más energía que toda Suecia.

Gran parte de la energía consumida por los circuitos, se transforma en calor y debe ser evacuado, con lo que se precisan potentes sistemas de climatización.

A esto debemos añadir, sistemas de monitorización, humidificación, sistemas anti-incendio…

Ello implica que en algunos centros de datos, por cada watio consumido por la electrónica, se precisen tres para mantenerlo refrigerado, con el grado óptimo de humedad, etc…

Hay diferentes asociaciones (ej: The GreenGrid), que intenan poner freno al crecimiento sin control de este efecto y promocionan la investigación de mejores prácticas, en la construcción, uso y buenas prácticas de gestión el los centros de datos de sus asociados.

Así nace una forma de medir el grado de optimización (lease ecología) energético de los centros de datos por medio de lo que se denomina PUE.

PUE = Potencia total consumida por las instalaciones / la potencia consumida por el equipamiento TI.

El resultado es un número, y a menor cuantía, mejor resultado.

El centro de datos perfecto (y utópico hoy por hoy), es aquel cuyo PUE sea 1, lo que significaría que cada watio empleado en el CPD se usa para “cómputo”.

Es por ello, que los grandes fabricantes suelen publicar sus PUE para demostrar lo ecológicos que son (se puede leer como: el ahorro de costes que se obtiene al optimizar el consumo eléctrico).

Otra fórmula ampliamente aceptada es el índicador DCiE:

DCiE = (Potencia de equipamiento TI x 100) / Total de potencia de las instalaciones

El resultado es un porcentaje, en cuyo caso la perfección sería del 100%, con el que se expresa qué porcentaje de la potencia consumida es utilizada por los equipos de “cómputo”, frente al consumo total.

Es mas que evidente, que situar un centro de datos en lugares como Irlanda (clima suave, húmedo, sin grandes contrastes entre estaciones) es mucho mas favorable para un centro de datos, desde la perspectiva del consumo que aquel situado en lugares con climatologías adversas (intente refrigerar un centro de datos situado en Sevilla el 5 de Agosto, y mantenga el grado de humedad óptimo (siempre buscando el PUE=1…:-))

Como ya hemos comentado en otras ocasiones, la forma del centro de datos, las corrientes de aire y su aprovechamiento, la indicencia del sol, climatología de cada día, carga del propio centro de datos, correcta extracción del aire caliente que arrojan las máquinas, aislamiento y otras muchas variables incidirán en una reducción del PUE (o si lo prefiere, aumento del DCiE).

Nota: En éste artículo se entenderá la palabra “cómputo”, de una forma no literal, sino como el conjunto de realizar los procesos de almacenamiento, comunicaciones, cómputo y otras..

27 abril 2010 at 10:26 2 comentarios

Entradas antiguas


junio 2017
L M X J V S D
« Ene    
 1234
567891011
12131415161718
19202122232425
2627282930  
junio 2017
L M X J V S D
« Ene    
 1234
567891011
12131415161718
19202122232425
2627282930  

Estadísticas

  • 55,917 visitantes