Esta é uma pergunta canônica sobre o iSCSI que podemos usar como referência.

O iSCSI é um protocolo que coloca comandos SCSI como carga útil em pacotes de rede TCP. Como tal, está sujeito a um conjunto diferente de problemas que, digamos, Fibre Channel. Por exemplo, se um link ficar congestionado e os buffers do comutador estiverem cheios, a Ethernet, por padrão, eliminará os quadros em vez de dizer ao host para diminuir a velocidade. Isso leva a retransmissões, o que leva a alta latência para uma parcela muito pequena do tráfego de armazenamento.

Existem soluções para esse problema, dependendo do sistema operacional do cliente, incluindo a modificação das configurações de rede. Para a lista a seguir de sistemas operacionais, como seria uma configuração ideal do cliente iSCSI? Isso envolveria alterações nas configurações dos comutadores? E o armazenamento?

• VMWare 4 e 5
• Windows Hyper-V 2008 e 2008r2
• Windows 2003 e 2008 em bare metal
• Linux em bare metal
• AIX VIO
• Qualquer outro sistema operacional que você ache relevante

Não conheço o VMWare, mas uso o Xenserver e o Hyper-V (R2).

Com minha configuração atual do Xenserver, tenho:

• 8 servidores Dell Poweredge 29xx
• 2 comutadores Dell Powerconnect 6248
• 2 Dell MD3000i SAN (iSCSI)

Eu configurei meus comutadores em uma configuração de caminhos múltiplos e otimizei para iSCSI:

• Separando meus switches em 3 VLANS (2 para tráfego iSCSI e 1 para gerenciamento)
• Usando JumboFrames
• Aplicando as otimizações "iSCSI" que o powerconnect possui

Cada servidor possui várias placas de rede para fornecer uma conexão a cada comutador, fornecendo redundância por vários caminhos entre os servidores e a SAN iSCSI. As VLANs iSCSI não contêm outro tráfego além do iSCSI.

Tenho o prazer de informar que, com essa configuração, o "cluster" do Xenserver funciona de maneira brilhante.

Além disso, tenho um servidor Windows 2008 conectado diretamente pelo iSCSI a uma HP SAN (servidor de arquivos antigo). Ele costumava rodar o Windows 2003 e costumava interromper a conexão (mesmo após uma reinstalação do 2003); no entanto, assim que atualizei para o Windows 2008, ele permanecerá conectado.

Ficarei feliz em responder a qualquer pergunta sobre minha configuração.

Esta não é uma resposta ... ainda. Essa é a estrutura da resposta genérica. Se você tiver tempo, preencha o que souber. Em relação à configuração de hardware específico, publique uma resposta separada para cada fornecedor, para que possamos manter essas informações organizadas e separadas.

Perfil de QoS para as portas, além de desativar o controle de tempestades, configurar o MTU para 9000, ativar o controle de fluxo e colocar as portas em portfast

Taxa de transferência e latência

Firmware, drivers e outros sistemas atualizados

MPIO

Jumbo Frames / MTU

À medida que a velocidade dos links de rede aumenta, o número de pacotes potencialmente gerados também aumenta. Isso gera cada vez mais tempo de CPU / interrupção gasto na geração de pacotes, que tem o efeito de sobrecarregar indevidamente o sistema de transmissão e ocupar uma quantidade excessiva de largura de banda de link com o enquadramento.

Os chamados quadros "jumbo" são quadros Ethernet que excedem o limite canônico de 1518 bytes. Embora os números possam variar com base nos fornecedores de switches, sistemas operacionais e placas de rede, os tamanhos de pacotes jumbo mais comuns são 9000 e 9216 bytes (o último é o mais comum). Dado que aproximadamente 6X os dados podem ser colocados em um quadro de 9K, o número de pacotes reais (e interrupções) é reduzido em uma quantidade semelhante no host. Esses ganhos são especialmente pronunciados em links de alta velocidade (por exemplo, 10GE) que enviam grandes volumes de dados (por exemplo, iSCSI).

A ativação dos jumbo-frames requer a configuração do host e do switch Ethernet e deve-se tomar um cuidado considerável antes da implementação. Várias diretrizes devem ser seguidas -

1.) Dentro de um determinado segmento Ethernet (VLAN), todos os hosts e roteadores devem ter a mesma MTU configurada. Um dispositivo sem configuração adequada verá os quadros maiores como erros de link (especificamente "gigantes") e os eliminará.

2.) No protocolo IP, dois hosts com tamanhos de quadro diferentes precisam de algum mecanismo para negociar um tamanho de quadro comum apropriado. Para o TCP, essa é a descoberta do caminho MTU (PMTU) e depende da transmissão de pacotes inacessíveis do ICMP. Verifique se o PMTU está ativado em todos os sistemas e se quaisquer regras de ACL ou firewall permitem esses pacotes.

Controle de fluxo Ethernet (802.3x)

Apesar de recomendado por alguns fornecedores de iSCSI, o controle de fluxo Ethernet 802.3x simples não deve ser ativado na maioria dos ambientes, a menos que todas as portas, NICs e links do switch sejam totalmente dedicados ao tráfego iSCSI e nada mais. Se houver outro tráfego nos links (como compartilhamento de arquivos SMB ou NFS, pulsações para armazenamento em cluster ou VMware, controle de monitoramento de equipes da NIC / monitoramento de tráfego etc.), o controle de fluxo 802.3x simples não deve ser usado, pois bloqueia portas inteiras e outro tráfego não iSCSI também será bloqueado. Os ganhos de desempenho do Ethernet Flow Control geralmente são mínimos ou inexistentes; o benchmarking realista deve ser realizado em todas as combinações OS / NIC / comutador / armazenamento, sendo consideradas para determinar se há algum benefício real.

A questão real da perspectiva dos servidores é: Interrompo o tráfego de rede se minha NIC ou rede estiver sobrecarregada ou começo a soltar e retransmitir pacotes? A ativação do controle de fluxo permitirá que os buffers da NIC sejam esvaziados no lado do receptor, mas sobrecarregará os buffers no lado do remetente (normalmente um dispositivo de rede fará buffer aqui).

Controle de congestionamento TCP (RFC 5681)

TOE (mecanismos de descarregamento TCP / IP)

iSOE (iSCSI Offload Engines)

LSO (Segmentação TCP / Descarga de Envio Grande)

Isolamento de rede

Uma prática recomendada comum para o iSCSI é isolar os iniciadores e os destinos de outro tráfego de rede que não seja de armazenamento. Isso oferece benefícios em termos de segurança, capacidade de gerenciamento e, em muitos casos, dedicação de recursos ao tráfego de armazenamento. Esse isolamento pode assumir várias formas:

1.) Isolamento físico - todos os iniciadores têm uma ou mais placas de rede dedicadas exclusivamente ao tráfego iSCSI. Isso pode ou não implicar em hardware de rede dedicado, dependendo dos recursos do hardware em questão e dos requisitos operacionais e de segurança específicos em uma determinada organização.

2.) Isolamento lógico - Encontrados principalmente em redes mais rápidas (por exemplo, 10GE), os iniciadores têm a marcação VLAN (consulte 802.1q) configurada para separar o tráfego de armazenamento e não armazenamento.

Em muitas organizações, mecanismos adicionais são empregados para garantir também que os iniciadores iSCSI não possam se conectar através dessas redes dedicadas e que, além disso, essas redes dedicadas não são acessíveis a partir de redes de dados padrão. As medidas usadas para fazer isso incluem listas de controle de acesso padrão, VLANs privadas e firewalls.

Algo sobre backplane e mudança de tecido aqui também.

QoS (802.1p)

vLAN (802.1q)

STP (RSTP, MSTP, etc)

Supressão de tráfego (controle de tempestade, controle de transmissão múltipla / ampla)

Segurança

Autenticação e Segurança

RACHAR

IPSec

Mapeamento LUN (Melhores Práticas)

Algumas considerações e pesquisas devem ser feitas subjetivamente em relação a:

1) Múltiplos caminhos - Sua solução SAN e seu sistema operacional, seja um hipervisor ou um sistema operacional bare metal, podem precisar de um software específico do fornecedor para que isso funcione corretamente.

2) Iniciadores - Você precisa verificar se o iniciador de software tem desempenho suficiente, com base nas demandas. Muitas NICs possuem recursos de descarregamento de iSCSI que podem melhorar significativamente a taxa de transferência, mas sabe-se que certos hipervisores mais antigos ficam bastante irritados com o suporte. As ofertas mais maduras (ESXi 4.1+) parecem agradáveis.

3) Segurança / Permissões - Verifique completamente quais iniciadores requerem acesso a quais LUNs ... você ficará em um dia ruim se um administrador em uma de suas máquinas Windows fizer um "disco de inicialização" em um disco que está realmente em uso por outro servidor como um armazenamento de dados VMware.