Concordo totalmente com a resposta da ynguldyn - na maioria das vezes, qualquer comutador moderno destinado a ser usado em um data center de servidor deve ser mais do que suficiente para suas necessidades e manter as coisas consistentes no seu ambiente é mais importante para você de uma perspectiva de suporte / capacidade de gerenciamento.
Dito isto, se você realmente quiser tirar o máximo proveito da configuração do iSCSI, use switches que tenham:
Memória buffer por porta suficiente . Idealmente algo > 512k por porta, mas há um trade-off aqui. Alguns switches usam buffers maiores para mascarar a velocidade de troca ruim, então você precisa procurar mais do que isso. Pouca memória buffer levará à perda de pacotes sob carga pesada e a camada TCP terá que reenviar pacotes que reduzirão a velocidade de forma drástica.
Capacidade de processamento por porta suficiente . Isso pode ser difícil de estabelecer - a melhor métrica para procurar é mudar de velocidade. Um comutador com velocidade de comutação de 100 microssegundos só pode lidar com 10k pacotes / s que não seriam capazes de alternar GigE na velocidade da linha, um com uma velocidade de comutação de 3 microssegura (em teoria) pode lidar com até 300k pacotes / s, o que é bom. Qualquer coisa abaixo de 12 microssec é provável que seja bom o suficiente. Mais rápido é melhor, mas os preços sobem de forma bastante dramática, já que esse número se dirige a dígitos baixos.
Suporte para controle de fluxo de hardware (802.3x) . Isso será inútil se as NICs e a matriz do servidor também não suportarem isso, mas se isso permitir, a rede iSCSI poderá lidar com o controle de fluxo com muito mais eficiência na camada 2, em vez de depender de um controle de congestionamento de nível mais alto, como os algoritmos de prevenção de congestionamento do TCP. será significativamente menos eficiente. Dito isso, é difícil encontrar um switch adequado que não o suporte hoje.
Suporte para quadros jumbo . Novamente, isso só será benéfico se o seu array iSCSI, o hardware do servidor e o SO também suportarem quadros jumbo. No nível mais básico, os Jumbo Frames reduzem a sobrecarga do protocolo e podem aumentar a taxa de transferência em 10 a 20%, mas esses ganhos dependem muito dos padrões de tráfego. Para transferências de dados estendidas de alta largura de banda, os quadros 9k Jumbo reduzirão a sobrecarga da CPU em sua matriz, servidores (e comutador) em até 80% também. Isso pode ou não ser significativo em seu ambiente, pois a sobrecarga inicial da CPU pode ser relativamente baixa. Interruptores low-end, por vezes, reivindicam suporte de quadros Jumbo, mas não suportam quadros Jumbo de 9k, que é o tamanho ideal geralmente acordado para o GigE, então verifique primeiro. Se a sua matriz não suporta quadros Jumbo, não há necessidade de se preocupar com isso, obviamente.
Alta capacidade de comutação e empilhamento de largura de banda . Para a GigE, você deve estar com o objetivo de obter > 1Gbps por porta, idealmente, 2Gbps para lidar com o tráfego full duplex na velocidade da linha em todas as portas. Para um comutador de 24 portas, você deseja que ele seja capaz de alternar 48Gbps internamente e ser capaz de ser empilhado \ uplinked em uma porcentagem significativa do que se você estiver usando vários switches. Para algumas arquiteturas iSCSI (por exemplo, HP Lefthand e Dell Equallogic), é necessário oferecer suporte a tráfego de largura de banda muito alto entre todas as portas em todos os arrays e a velocidade de comutação agregada se torna muito importante. Para switches que suportam ajustes mistos de 1GigE e 10GigE, a largura de banda de comutação total deve cobrir todas as portas em alta velocidade no modo full duplex.
Spannning Tree. Você quer ser capaz de desativá-lo completamente se o seu ambiente iSCSI for simples e isolado de todo o resto ou se ele suportar Rapid Spanning Tree \ Port Rápida \ Edge Ports onde você puder Desabilite seletivamente o comportamento completo da árvore de abrangência em portas específicas.