Como a confiabilidade é alcançada com SCSI e SAN?

Question

Sou muito novo no SCSI e, na verdade, nem tenho certeza se esse é o fórum correto para perguntar. (Eu fiz porque eu encontrei algumas questões SCSI :) Então, por favor, sinta-se livre para melhorar / migrar esta questão.

Estou jogando com a transmissão Fibre Channel e leio em um documento interno que, ao contrário do TCP, o SCSI sobre o FCP-3 não é garantido, por isso minhas perguntas:

1. isso significa que o padrão / protocolo SCSI em si não é confiável? Mas acho que já foi muito popular para discos rígidos. Como foi resolvida a questão da confiabilidade?
2. da mesma forma, como a confiabilidade é tratada em um ambiente SAN?

Answer 1

Pode ser um para o ServerFault.

Mas você está bem correto. O Fibre Channel não possui os mesmos mecanismos de proteção que o TCP. É mais parecido com o UDP a esse respeito (embora seja uma analogia fraca) e por muitas das mesmas razões - para algumas aplicações, o TCP é uma má solução devido a esses mecanismos de confiabilidade - seu fluxo pode "parar" para retransmitir e que fere um aplicativo quase em tempo real mais do que um pacote descartado faz. A latência de IO de armazenamento começa a "doer" quando você é mais do que cerca de 20 ms, e isso não é tempo suficiente para o TCP fazer isso realmente.

O que acontece para o FCP é que o driver SCSI no nó de extremidade lida com a confiabilidade, porque, como parte disso, também pode fazer o balanceamento de carga. Geralmente, você não anexará uma fibra única, mas terá HBAs duplos com dois caminhos independentes para armazenamento.

Portanto, o seu driver roteia os pacotes da maneira que preferir (alguns são mais inteligentes do que outros - a maioria faz vários caminhos nos dias de hoje, mas alguns fazem alguns caminhos múltiplos adaptáveis) e rastreia quais IOs foram reconhecidos ou não. O SO pode enfileirar IO quando apropriado, ou ... bem, não, se achar que é uma má ideia. Na prática, isso é feito de qualquer maneira como parte dos mecanismos de cache do sistema de arquivos de rotina.

É por isso que, por exemplo, open tem a opção O_DIRECT :

   O_DIRECT (since Linux 2.4.10)
          Try to minimize cache effects of the I/O to and from this
          file.  In general this will degrade performance, but it is
          useful in special situations, such as when applications do
          their own caching.  File I/O is done directly to/from user-
          space buffers.  The O_DIRECT flag on its own makes an effort
          to transfer data synchronously, but does not give the
          guarantees of the O_SYNC flag that data and necessary metadata
          are transferred.  To guarantee synchronous I/O, O_SYNC must be
          used in addition to O_DIRECT.  See NOTES below for further
          discussion.

    

Answer 2

Eu encontrei um artigo informal fazendo a mesma comparação, que corresponde à impressão grosseira que eu tinha. O artigo também mostra vários caminhos para sobreviver à falha de um switch FC ou de um dos cabos em uma SAN grande, como menciona @Sobrique.

SCSI doesn’t take kindly to dropped commands. It’s a bit of a misconception that SCSI can’t tolerate a lost command. It can, it just takes a long time to recover (relatively speaking). I’ve seen plenty of SCSI errors, and they’ll slow a system down to a crawl. So it’s best not to lose any SCSI commands.

link

Parece que o FCP não garante formalmente a entrega , mas ... Se você ler o artigo da Wikipedia, o FibreChannel especificará uma determinada Taxa de Erro de Bit (aceitável / esperado). O TCP é projetado para operar em links que levam muito menos cuidado com pacotes do que o FibreChannel faz.

O FibreChannel também inclui controle de fluxo, para evitar o descarte de pacotes devido a buffers de congestionamento / transbordamento. O IP não (e não espera que as redes subjacentes façam isso de qualquer forma).

Por exemplo, o Google tem este papel legal onde eles estavam medindo as taxas de perda de pacotes TCP em média entre 1% e 20% ou até mais . (Eles defendem que os ISPs usem a tecnologia que resultou em 1% de perdas (modelagem) e não os 20% + perdas (policiamento). Essas tecnologias são como as redes IP geralmente lidam com o problema de congestionamento).

Acho que a maioria das implementações SCSI tenta novamente os comandos com falha. Eu não sei o quão padronizado é - eu espero que seja possível sintonizar de várias maneiras. Tecnicamente isso também não garante a entrega, da mesma forma que você pode esperar que o TCP termine (o TCP iria desistir e fechar a conexão).