SAN MTBF típico

Question

Estamos usando uma SAN em um projeto no trabalho, e há um pouco de debate em torno do fato de que, tecnicamente, é um ponto único de falha. Ninguém parece ter dados concretos.

A SAN em questão é uma única caixa física, mas com componentes internos redundantes (desculpe - não tenho certeza3 qual o nível de RAID que possui, mas posso descobrir).

Qual é o MTBF típico para uma SAN? O PM tem isso no registro de risco de projetos como "bastante comum" - nunca ouvi falar de uma queda de SAN, mas não tenho estatísticas para mostrar a probabilidade de isso acontecer.

Alguém tem alguma informação útil?

    

Answer 1

Sem saber a SAN exata em questão e como ela é configurada e gerenciada, qualquer resposta a essa pergunta é um palpite. Eu digo isso por 2 motivos:

1. Algumas SANs são melhores que outras. Temos um antigo EMC CX500 que está em produção há 7 anos sem um único soluço. Temos um Dell MD3000i que teve problemas constantes. Você recebe o que você paga.

2. Até mesmo a melhor SAN, quando gerenciada ou mal configurada, pode ter pouco tempo de atividade. Eu vi um administrador tolo fazendo com que um EMC Symmetrix de US $ 2 milhões falisse duas vezes em um mês. Antes de o contratarmos, ele ficou ativo por quase quatro anos seguidos sem problemas.

Answer 2

Não é realmente comum, na verdade eu diria que é quase tão comum quanto perder energia para toda a sala - como se eles estivessem configurados e mantidos corretamente, a perda de energia é a única maneira real de perder uma SAN completa. caixa.

Dito isso, você precisa garantir que eles sejam alimentados por dois no-breaks separados, com controladores duplos, comutadores duplos, fibras roteadas de forma diversa e que você planeje seu layout de prateleira / matriz para compensar a perda total da prateleira. Se você fizer isso, estará tão bem quanto possível, sem um segundo site.

    

Answer 3

Desde o início do ano, tivemos todos os tipos de problemas, até o ponto em que a "próxima janela de manutenção disponível" era um eufemismo para a SAN estar inativa. Se você ouvir as vendas, elas são todas sólidas. Na prática, você não tem o conhecimento necessário para testar a SAN antes de iniciar a produção, por isso cabe às setas do destino expor seus problemas de configuração em momentos de alta demanda.

O software SAN incrivelmente complicado ou a falha na configuração é uma quantidade desconhecida em comparação com as unidades de disco reais e outros hardwares. O que isso significa, em última análise, é que você pode adicionar o máximo de redundância física que quiser, mas já que todos executam o mesmo software quebrado, você ainda tem um único ponto de falha.

Dito isto, parece que estamos a correr muito mais suavemente desde que desmontamos tudo para um patch de firmware. O relatório de resumo do nosso reparo de SAN me deixa preocupado que um pouco de pensamento mágico continue sendo atribuído ao SAN.

    

Answer 4

Como outros apontaram, não é comum que um back-end de armazenamento adequadamente configurado e específico (controladores redundantes, energia, switches, etc.) diminua. Eu seriamente pediria ao PM que discutisse, por fim, o pensamento por trás do risco comum.

Tecnicamente, vale sempre documentar uma "falha de ponto único" como parte de uma avaliação de risco, mas há uma discussão séria a ser feita sobre se o armazenamento totalmente redundante em uma configuração de HA representa um "ponto único de falha". Pode ou não depender da sua organização e do aplicativo. Se for um ponto único de falha, vale a pena discutir os cenários de falha por perda de serviço para todo o datacenter (já que é improvável que haja uma falha total de uma SAN HA redundante que deixou tudo disponível e disponível).

Lidar com esses tipos de cenários é bastante caro ... datacenters redundantes para começar e coisas como malhas geograficamente esticadas, várias SANs totalmente redundantes, "replicação em tempo real" para a parte de armazenamento. Os cenários e aplicativos que exigem essas coisas não são tão comuns.

Apenas minha experiência pessoal: Eu me deparei com erros de firmware e controladores que causam problemas isolados. Em uma ocasião rara, eu até encontrei um bug que fazia com que um controlador em um par ativo-ativo fizesse um despejo e acionasse o failover. Isso não causou tempo de inatividade.

Eu já ouvi falar de cenários de pesadelo, como o controlador split-brain ou o que leva ao colapso total do array, mas é raro e nunca é definitivo que isso não seja devido a erro humano ou configuração incorreta. (erro humano e configuração incorreta são problemas imensos ... Eu não quero menosprezá-los ... mas eles não são "spofs" no mesmo sentido que um único SAN.)