Consulta Técnica: Netapp & iSCSI

Anónimo me pregunta:

"Primero: Realmente he estado buscando informacion de netapp y VM, y realmente muy interesante.Tengo una consulta: La gente de NetApp jura y perjura que SQL (120Gb) no degrada con iSCSI. Alguna sugerencia? "

Bueno... esto se sale un poco de la dinámica que pretendo darle a este blog, pero como los equipos de Netapp están entre mis caprichos más queridos, he decidido hacer una excepción.

En cualquier caso, os agradecería que dejáseis un correo de respuesta para este tipo de consultas, para poderos responder personalmente.

Vamos a ver. A esa pregunta no puedo responder con un "sí" o un "no", así que me extenderé un poco.

El rendimiento de un SQL no depende exclusivamente del almacenamiento. Dependerá de la plataforma hardware, la configuración del SQL, la aplicación que use la base de datos, y por último, del nivel de mantenimiento del mismo. En otras palabras, si esperas que tu SQL "vuele" por ponerle un Netapp, un EMC o un Hitachi detrás, quizá te lleves una decepción.

Los fanáticos de los IOPS (IO Operations per second) Defienden, y no sin razón, que FC puede dar más rendimiento que cualquier otra tecnología. Por otro, todos sabemos que un host Wintel es incapaz de mantener tasas sostenidas de más de 600 Kb Mb por segundo (sea cual sea el medio).

Otra de las "ventajas" de FC es que la infraestructura es dedicada, y normalmente el integrador/fabricante llega, la instala, configura y listo. Esto, evidentemente tiene un coste que hay que asumir.

iSCSI ofrece un rendimiento (teórico, al menos) de entre un 15 a un 20% menos. Pero no nos confundamos: de un 15 a un 20% menos que el mayor rendimiento posible en un entorno FC. Nuestras bases de datos, exchanges y similares no alcanzan, ni de lejos, el máximo rendimiento de un enlace FC, por lo que, en la mayoría de los casos, la diferencia es inferior al 1% (este 1% suele ir relacionado al overhead que el procesamiento IP supone para los procesadores del servidor en cuestión).

Una de las ventajas claras de iSCSI es, paradójicamente, uno de los motivos por los que iSCSI es despreciado por algunos admins de sistemas: La capacidad de usar la infraestructura IP existente. No es el primer proyecto que veo con problemas porque se ha conectado una flamante SAN iSCSI a un switch Netgear o procurve de gama baja.

Otro aspecto donde iSCSI supera ampliamente a FC es en la simplicidad: Como dice la propaganda, configure usté el IP, instale y configure el Initiator, ofrezca las LUN y a andar. Realmente es así. Una instalación FC es compleja, con múltiples puntos críticos y con una configuración casi de gurú. Las actualizaciones en una SAN FC son laboriosas y arriesgadas, mientras que en iSCSI son bastante simples.

Hay un tercer dato que se tiende a obviar, y que en el caso de Netapp adquiere gran importancia: El hardware de la SAN IP. Mientras IBM, EMC, etc utilizan hardware específico (ASICs, etc), limitado y caro por definición, Netapp se ha volcado en el hardware estandar: PCI-e, Opterons e ingentes cantidades de memoria. Como resulta de esto, Netapp garantiza un path de alta velocidad desde el cabezal del disco hasta la GbitE de salida. De hecho, casi el 40% de las operaciones de IO sobre un Netapp las estás realizando en una memoria caché interna de varios GB, protegida por una batería que garantiza la supervivencia del dato en caso de pérdida de fluído eléctrico.

Otro aspecto que afecta sensiblemente al rendimiento es la reconstrucción de discos en caso de fallo de uno. Las arquitecturas tradicionales basadas en RAID 5 son realmente pesadas a la hora de reconstruir un disco fallado. Las reconstrucciones suelen ser largas, con degradaciones de entre el 10% y el 20% de rendimiento durante la misma. Dado el estado de vulnerabilidad de el RAID durante una reconstrucción (ya que RAID5 no soporta el fallo de dos discos), nos interesa que la ventana de reconstrucción sea lo más limitada posible, lo que supone asignar alta prioridad al proceso de reconstrucción. Recordemos que en RAID 5, la paridad se distribuye entre todos los discos, lo que obliga a leer de todos ellos, compartiendo el IO de estos entre la reconstrucción y el servicio.

Netapp basa su esquema de protección de datos en la especificación RAID4, dedicando un disco para paridad. Esto significa que, en las reconstrucciones, sólo un disco es accedido en lectura para obtener los datos a reconstruir. Por otra parte, refuerzan esta implementación con el uso de un segundo disco como paridad doble, lo que permite el fallo de DOS discos simultáneamente en un mismo RAID. Con esta implementación, que ellos denominan RAID-DP (o RAID 6, a todo hay que ponerle un nombre) las ventanas de reconstrucción (consideradas a menudo ventanas de vulnerabilidad) quedan cubiertas. Hay que tener en cuenta que, los discos de un RAID, si han sido adquiridos al mismo tiempo, comenzarán a fallar más o menos en la misma época. La degradación, tanto en rendimiento como en fiabilidad de los discos, es una realidad.

He tenido la oportunidad de instalar y explotar SQL Servers, Oracles y VMware sobre Network Appliance, incluso en entronos mixtos (FC e iSCSI sobre netapp y iSCSI sobre netapp/FC sobre IBM/EMC) y no hay diferencia de rendimiento puntual. Donde sí la hay, y es a favor de Network Appliance, es en el medio plazo. Mientras con IBM y EMC los tiempos de reconstrucción afectaban al usuario, con Netapp ni se enteraban.

Netapp en españa tiene un equipo técnico muy cualificado, con mucha experiencia y muchas horas de vuelo en lo que a almacenamiento se refiere.

Espero haberte sido de ayuda.

En respuesta a tu pregunta... Créeles. Los equipos son fascinantemente rápidos, simples y, sobre todo, seguros.