Políticas de SAN: regras gerais práticas?

Question

Estou sendo encarregado de definir políticas de SAN para uma organização externa. Eu não sou um administrador de sistemas, estes não são sistemas sobre os quais temos autoridade. Eu também não sou especialista em SAN. Quem disse que o trabalho tinha que fazer sentido?

Apresentei alguns pontos com base na documentação fornecida pelos fornecedores envolvidos (que a organização externa que está atualmente executando a SAN não se preocupou em investigar). Coisas como "não coloque alto armazenamento de teste de I / O na mesma fatia que os armazenamentos de dados Prod", que parecem ser óbvias, mas claramente não são.

Alguma recomendação sobre as convenções gerais da SAN que devem estar implementadas para melhorar o desempenho e a confiabilidade?

Específico para nossa configuração (hardware EMC, DB2), estes são os principais itens que tenho:

• Idealmente, cada unidade lógica (LUN) da SAN será distribuída entre vários dispositivos físicos para permitir E / S simultâneas, melhorando assim o desempenho.
• Cada LUN deve ser dedicado ao uso único (por exemplo, o repositório do DB2 para um aplicativo específico)
• Para que os logs de transação do DB2 devam estar localizados em um LUN separado em um fuso fisicamente separado ou conjunto de eixos a partir dos dados da tabela
• LUNs de dados devem ser RAID-5, pois oferecem o melhor desempenho com redundância reduzida
• Log LUNs deve ser RAID-10 para fornecer redundância máxima
• Se as LUNs estiverem configuradas para usar sistemas de arquivos em vez de partições brutas (o que é recomendado), os espaços de tabela devem usar o NO FILE SYSTEM
• cláusula CACHING para melhorar o desempenho

Answer 1

Antes de escrever uma política, seria útil saber para o que você está tentando definir uma política. É para um ótimo desempenho? Proteção de dados? Algo específico em relação às políticas de retenção da empresa? Podemos presumir que é apenas um documento genérico de desempenho / confiabilidade baseado em sua declaração?

A razão pela qual peço é que uma SAN (como qualquer equipamento de rede) geralmente é personalizada para se adequar a uma função. Sua configuração de hardware pode afetar muito as recomendações que se pode fazer para isso. Por exemplo, os LUNs SQL geralmente são melhores quando são compostos de vários discos rígidos (dependentes de fuso), enquanto algo como compartilhamentos de usuários ou dados de arquivamento é mais adequado para volumes maiores e lentos (você parece estar ciente disso). Dito isso, seria difícil definir definitivamente um nível de RAID, já que diferentes fornecedores têm várias visões disso. Por exemplo, a EMC pode achar que o RAID10 é o preferido, enquanto a NetApp acredita que um RAID 6 de 24 eixos é ideal.

Geralmente eu diria:

• Isole LUNs de dados de LUNs de banco de dados / log
• Os níveis de RAID e as contagens do fuso devem ser determinados pelas recomendações do aplicativo e do fornecedor
• Colocar dados de baixa prioridade (como compartilhamentos de usuários e dados de arquivamento) nos discos mais lentos
• Idealmente, os LUNs de banco de dados / log têm várias unidades pequenas e rápidas para aumentar a contagem de fusos
• Aplicativos intensivos de E / S devem ser divididos entre controladores (se isso for uma opção)
• Se você tiver um ambiente de teste que deve ser isolado para limitar seu impacto no ambiente de produção (controlador / volume separado)

Será difícil oferecer mais do que essas opções muito genéricas, porque você começa a incluir recomendações específicas de fornecedores, hardware e aplicativos. Você também entra na política de segurança e de empresa. Você provavelmente teria mais sucesso ao definir requisitos para um aplicativo específico do que criar um guia genérico de SAN.

    

Answer 2

Cada LUN deve ser distribuído entre fusos no back-end de seus destinos de armazenamento, mas retornando aos adaptadores de front-end, a demanda possível (# trocas * tamanho das trocas * número de servidores) deve ser balanceada. Por exemplo, se eu não alterar meus servidores, eles provavelmente terão uma profundidade de fila de 254. Se minhas trocas forem de 4 quadros cada (8k), cada um desses servidores poderá sufocar 2k de um FA. Eu gostaria de equilibrar minha SAN para que a carga total possível e a carga possível em determinados momentos (ocorrências de tráfego de backup quando o tráfego diário não está) estejam equilibradas. Sinta-se à vontade para definir os limites de profundidade de fila e capturar aqueles que excederem. Se você não sabe como pegar os infratores do QD, eu posso te mostrar.

Eu também tentaria impor uma política: se você não estiver usando a SAN, não será zoneado e sua porta ficará off-line. Muitos ambientes fornecem SAN a todos os servidores, mas não ficam imediatamente (nunca?) On-line na SAN. Eles tendem a ativar / desativar / ativar / desativar / ativar / desativar, e são esses dispositivos que causam tempestades de atualizações nos tecidos. Vamos sufocá-los antes que eles se tornem um problema.

Coloque os dispositivos em um VSAN ou VF padrão: VSAN0001 no Cisco ou VFAB128 no Brocade. Quando um usuário decide onde a porta precisa estar, mova-o para um VSAN ou VF. O VSAN0001 ou o VF128 não passam ISLs / XISLs - isso reduz o risco de tempestade de transmissão.

Os novos dispositivos devem fazer com que o solicitante indique se eles são de caminho único ou multipath, e se multipath, se eles são passivos ativos, multi-caminho balanceado ou multi-caminho desequilibrado para que, quando não estiverem balanceados, você possa ver se ocorreu um problema de configuração ou se as ferramentas de vários caminhos se comportaram mal.

Nomeie tudo. Aliases ajudam. Tenha um esquema de nomenclatura, para que o Oracle14_HBA0 faça com que você espere um Oracle14_HBA1. Isso ajuda quando há um problema: você pode decidir se o Oracle14_HBA0 vale a pena sair da cama agora ou esperar até o próximo dia de trabalho.

Exija que os solicitantes solicitem armazenamento em termos de latência (ms) contra demanda (MB / s ou IOPS). Eles vão querer dizer "Tier1! Tier1! Minhas coisas balançam, eu preciso de Tier1" sem saber o que é isso. Pressione para obter um SLA como "40ms por 200MByte / s", que é uma latência razoavelmente fácil no link de caminho único de 2 GB. Se eles não souberem, diga a eles "40ms @ 200mb / sec" e espere que eles reafirmem. Eles acabarão migrando para 9ms para LUNs de log de intenção de banco de dados, mas não imediatamente, e você terá seus LUNs baseados em Flash e loucos por SAS apenas para os locais que precisam deles.

O limite de taxa VMAX é seu amigo: sufoque a demanda em rajada antes de ativar sua matriz em write-pendente. Veja acima: "40ms @ 200MB / seg".

Esses são alguns pensamentos baseados no ensino do FibreChannel para até 50 pessoas de cada vez e para ver os problemas que eles têm.

    

Answer 3

Outros já ofereceram conselhos, vou acrescentar algumas sugestões:

• Todo servidor deve ter dois caminhos fisicamente distintos para armazenamento. Isso significa dois HBAs por servidor, passando por dois conjuntos completamente separados de comutadores SAN em duas malhas separadas, para dois controladores de back-end diferentes. Não economize e compre um HBA de porta dupla - que oferece largura de banda, mas não resiliência. (Se possível, tenha as fibras usando diferentes rotas físicas através da sala do servidor).

• Multipath tudo. Pelo menos dois caminhos, adicione mais se você precisar de um melhor desempenho.

• Use aliases para HBAs e controladores. Zona para esses aliases. Stick com zoneamento único iniciador. É o menos provável que cause problemas se você não entender completamente as implicações. Nomeie suas zonas com base no que elas contêm. Como opção, inclua um agrupamento lógico no nome da zona. ('por exemplo, oracle_clus2_hostname_HBA0_array_port4)

• Pergunte sobre desempenho, espere receber 'não sei' ou 'muito!' digite respostas. É raro obter uma boa resposta sobre esse tipo de pergunta, mas é importante em um ambiente de armazenamento consolidado. O ponto principal da consolidação é obter um melhor desempenho de pico e uma média mais baixa - isso se ajusta à maioria das cargas de trabalho, porque as operações de 'usuário enfrentando' se preocupam mais com uma única resposta de transação (e não se preocupam com isso).

• Não fique preso a tipos de RAID - isso pode ser um pouco falso. O armazenamento em cache faz mais diferença que os tipos de RAID, e o armazenamento em cache afeta diferentes tipos de carga de trabalho de diferentes maneiras.

Um IO lido está sob uma restrição de tempo difícil - para completar a leitura para o host, o array tem para buscar o bloco do disco. Caches pré-buscam e tentam adivinhar o que será necessário em seguida - o IO de leitura tão previsível é mais rápido do que aleatório.

O Write IO está sob uma restrição de tempo flexível - você pode gravar o cache e reconhecer a gravação no host - e desdobrar no disco posteriormente. Isso significa que você pode fazer coisas interessantes, como escrever gravações de coalescência e de faixa completa, e reduzir significativamente a "sobrecarga" do tipo de RAID. Com uma carga de trabalho sequencial, como logs / diários, o RAID-5 pode, na verdade, ser mais rápido que o RAID 1 + 0 como resultado.

O termo geralmente usado é 'write penalty' - quantas operações de disco são necessárias para 'completar' uma gravação [1].

• RAID 0, a penalidade de gravação é 1 - um IO de gravação necessário por gravação recebida.
• RAID 1 - você escreve para ambos os espelhos, então escreva uma penalidade de 2.
• RAID 5 - você precisa escrever para um fuso, ler / atualizar paridade. A penalidade de gravação é de 4.
• RAID 6 - como o raid 5, mas com dois cálculos de paridade, então atrai uma penalidade de escrita de 6.

Isso significa uma carga de trabalho de gravação aleatória pura - você precisa dividir seus IOPs utilizáveis teóricos por fuso (~ 150 para FC, ~ 75 para SATA) por essa penalidade de gravação.

Para todos os tipos de ataque, a 'penalidade de leitura' é basicamente a mesma - você precisa completar uma leitura em algum lugar da sua matriz. Você obtém uma pequena vantagem do RAID1, porque ele pode ser lido de dois locais diferentes e ver qual responde mais rápido, mas não há muito nele - os discos ainda precisam girar e procurar.

Com o coalescing de tarjas - que a maioria das matrizes pode fazer com gravações sequenciais - você pode reduzir a penalidade de gravação. Se você tem toda uma faixa de paridade para o seu RAID 5, por exemplo - você não precisa ler de volta a paridade, você pode calcular a partir do que está no seu cache. Nesse cenário, escreva penalidade cai para 1 + 1 / Raidgroup tamanho assim para um 4 + 1 grupo RAID 5: 1,25. O que significa que é melhor que o RAID 1 + 0 para cargas de trabalho de gravação serial sustentada. (por exemplo, registros do banco de dados)

Resiliência - você tem alguns cálculos diferentes para fazer, mas eu ainda digo - não fique muito preso nos tipos de RAID - você terá falhas de composição se tiver uma linha de tempo suficiente Independentemente disso, então aqui não há atenuação precisando de uma solução de recuperação decente. Existem diferenças de resiliência entre os tipos de RAID, mas o único que você definitivamente não deve usar é o RAID0 :).

(Outros tipos de RAID personalizados existem. Por exemplo, a NetApp usa algo que chamam de RAID-DP para paridade dupla. É basicamente RAID-4 com um eixo de paridade extra, mas devido ao modo como o NetApps usa seu sistema de arquivos "WAFL" pena de gravação muito baixa)