Esta es una pregunta canónica sobre iSCSI que podemos usar como referencia.
iSCSI es un protocolo que coloca comandos SCSI como carga útil en paquetes de red TCP. Como tal, está sujeto a un conjunto diferente de problemas que, por ejemplo, Fibre Channel. Por ejemplo, si un enlace se congestiona y las memorias intermedias del conmutador están llenas, Ethernet, por defecto, soltará tramas en lugar de decirle al host que disminuya la velocidad. Esto conduce a retransmisiones que conducen a una alta latencia para una porción muy pequeña del tráfico de almacenamiento.
Existen soluciones para este problema, según el sistema operativo del cliente, incluida la modificación de la configuración de red. Para la siguiente lista de sistemas operativos, ¿cómo sería una configuración óptima de cliente iSCSI? ¿Implicaría cambiar la configuración de los interruptores? ¿Qué pasa con el almacenamiento?
- VMWare 4 y 5
- Windows Hyper-V 2008 y 2008r2
- Windows 2003 y 2008 en metal desnudo
- Linux en metal desnudo
- AIX VIO
- Cualquier otro sistema operativo que creas que sería relevante
fuente
Respuestas:
No estoy familiarizado con VMWare, pero uso Xenserver y he usado Hyper-V (R2).
Con mi configuración actual de Xenserver tengo:
He configurado mis conmutadores en una configuración de múltiples rutas y optimizado para iSCSI mediante:
Cada servidor tiene múltiples tarjetas de red para proporcionar una conexión a cada conmutador, lo que a su vez brinda redundancia a través de múltiples rutas entre los servidores y la SAN iSCSI. Las VLAN iSCSI no contienen otro tráfico que iSCSI.
Me complace informar que con esta configuración, el "clúster" de Xenserver funciona de manera brillante.
En una nota al margen, tengo un servidor Windows 2008 conectado directamente por iSCSI a un HP SAN (antiguo servidor de archivos). Solía ejecutar Windows 2003, y regularmente desconectaba la conexión (incluso después de una reinstalación de 2003); sin embargo, tan pronto como actualicé a Windows 2008, permanece conectado.
Estaré encantado de responder cualquier pregunta sobre mi configuración.
fuente
Esta no es una respuesta ... todavía. Este es el marco para la respuesta genérica. Si tiene tiempo, complete todo lo que sabe. Con respecto a la configuración de hardware específico, publique una respuesta separada para cada proveedor para que podamos mantener esa información organizada y separada.
Perfil de QoS para los puertos, además de desactivar el control de tormentas, configurar MTU en 9000, activar el control de flujo y poner los puertos en portfast
Rendimiento y latencia
Firmware, controladores y otros sistemas actualizados
MPIO
Marcos Jumbo / MTU
A medida que aumenta la velocidad de los enlaces de red, también aumenta el número de paquetes potencialmente generados. Esto produce más y más tiempo de CPU / interrupción dedicado a generar paquetes, lo que tiene el efecto de cargar indebidamente al sistema de transmisión y ocupar una cantidad excesiva de ancho de banda del enlace con el encuadre.
Las llamadas tramas "jumbo" son tramas Ethernet que exceden el límite canónico de 1518 bytes. Si bien los números pueden variar según los proveedores de conmutadores, sistemas operativos y NIC, los tamaños de paquetes jumbo más típicos son 9000 y 9216 bytes (este último es el más común). Dado que aproximadamente 6X los datos se pueden poner en un marco de 9K, el número de paquetes reales (e interrupciones) se reduce en una cantidad similar en el host. Estas ganancias son especialmente pronunciadas en enlaces de mayor velocidad (es decir, 10GE) que envían grandes volúmenes de datos (es decir, iSCSI).
La habilitación de tramas gigantes requiere la configuración tanto del host como del conmutador Ethernet y se debe tener mucho cuidado antes de la implementación. Se deben seguir varias pautas:
1.) Dentro de un segmento Ethernet (VLAN) dado, todos los hosts y enrutadores deben tener la misma MTU configurada. Un dispositivo sin la configuración adecuada verá marcos más grandes como errores de enlace (específicamente "gigantes") y los descartará.
2.) Dentro del protocolo IP, dos hosts con diferentes tamaños de trama necesitan algún mecanismo para negociar un tamaño de trama común apropiado. Para TCP, este es el descubrimiento de ruta MTU (PMTU) y se basa en la transmisión de paquetes ICMP inalcanzables. Asegúrese de que PMTU esté habilitado en todos los sistemas y que las reglas de ACL o firewall permitan estos paquetes.
Control de flujo de Ethernet (802.3x)
A pesar de ser recomendado por algunos proveedores de iSCSI, el simple control de flujo de Ethernet 802.3x no debe habilitarse en la mayoría de los entornos a menos que todos los puertos de conmutador, NIC y enlaces estén totalmente dedicados al tráfico de iSCSI y nada más. Si hay algún otro tráfico en los enlaces (como el intercambio de archivos SMB o NFS, latidos para almacenamiento en clúster o VMware, control de equipo de NIC / monitoreo del tráfico, etc.), el control de flujo 802.3x simple no debe usarse ya que bloquea puertos enteros y otro tráfico que no sea iSCSI también se bloqueará. Las ganancias de rendimiento del control de flujo de Ethernet a menudo son mínimas o inexistentes, la evaluación comparativa realista debe realizarse en todas las combinaciones de OS / NIC / conmutador / almacenamiento que se consideran para determinar si hay algún beneficio real.
La pregunta real desde la perspectiva de los servidores es: ¿detengo el tráfico de red si mi NIC o red se desborda, o empiezo a soltar y retransmitir paquetes? Activar el control de flujo permitirá que las memorias intermedias se vacíen en la NIC en el lado del receptor, pero estresará las memorias intermedias en el lado del emisor (normalmente un dispositivo de red se almacenará aquí).
Control de congestión TCP (RFC 5681)
TOE (motores de descarga TCP / IP)
iSOE (motores de descarga iSCSI)
LSO (segmentación TCP / descarga de envío grande)
Aislamiento de red
Una práctica recomendada común para iSCSI es aislar tanto los iniciadores como los objetivos de otro tráfico de red que no sea de almacenamiento. Esto ofrece beneficios en términos de seguridad, capacidad de administración y, en muchos casos, dedicación de recursos al tráfico de almacenamiento. Este aislamiento puede tomar varias formas:
1.) Aislamiento físico: todos los iniciadores tienen una o más NIC dedicadas exclusivamente al tráfico iSCSI. Esto puede o no implicar hardware de red dedicado dependiendo de las capacidades del hardware en cuestión y los requisitos operativos y de seguridad específicos dentro de una organización determinada.
2.) Aislamiento lógico: se encuentra principalmente en redes más rápidas (es decir, 10GE), los iniciadores tienen etiquetado VLAN (consulte 802.1q) configurado para separar el tráfico de almacenamiento y el de no almacenamiento.
En muchas organizaciones, se emplean mecanismos adicionales para garantizar que los iniciadores iSCSI no puedan comunicarse entre sí a través de estas redes dedicadas y que, además, estas redes dedicadas no sean accesibles desde las redes de datos estándar. Las medidas utilizadas para lograr esto incluyen listas de control de acceso estándar, VLAN privadas y firewalls.
Algo sobre el plano posterior y el cambio de tela aquí también.
QoS (802.1p)
vLAN (802.1q)
STP (RSTP, MSTP, etc.)
Supresión de tráfico (control de tormentas, control de transmisión múltiple / amplia)
Seguridad
Autenticación y seguridad
CAP
IPSec
Mapeo de LUN (mejores prácticas)
fuente
Alguna consideración e investigación debe ser tomada subjetivamente con respecto a:
1) Ruta múltiple: su solución SAN y su sistema operativo, ya sea hipervisor o sistema operativo simple, pueden necesitar un software específico del proveedor para que funcione correctamente.
2) Iniciadores: debe verificar si el iniciador de software tiene un rendimiento suficiente en función de las demandas. Muchos NIC tienen capacidades de descarga iSCSI que pueden mejorar significativamente el rendimiento, pero se sabe que ciertos hipervisores más antiguos se molestan mucho con el soporte. Las ofertas más maduras (ESXi 4.1+) parecen ser agradables.
3) Seguridad / Permisos: asegúrese de verificar completamente qué iniciadores requieren acceso a qué LUN ... se encontrará en un mal día si un administrador en una de sus máquinas Windows hace un "disco de inicialización" en un disco que es realmente utilizado por otro servidor como un almacén de datos de VMware.
fuente