it-swarm-pt.tech

Projeto de disco do SQL Server em um ISCSI SAN

É prática padrão separar os arquivos de log e de dados para separar os discos do sistema operacional (tempdb, backups e arquivos de troca também) Essa lógica ainda faz sentido quando suas unidades são todas SAN e seu LUNS não são gravados em discos específicos ou conjuntos de raid - eles são apenas parte do número x de unidades no SAN e o LUN é apenas alocação de espaço

27
CPU_BUSY

Logs e unidades de dados têm padrões de acesso a dados diferentes que estão em conflito entre si (pelo menos em teoria) quando compartilham uma unidade.

Gravações de log

O acesso ao log consiste em um grande número de pequenas gravações sequenciais. De maneira um tanto simplista, os logs do banco de dados são buffers de anel contendo uma lista de instruções para gravar itens de dados em locais específicos no disco. O padrão de acesso consiste em um grande número de pequenas gravações sequenciais cuja conclusão deve ser garantida - portanto, são gravadas no disco.

O ideal é que os registros estejam em um volume silencioso (ou seja, não compartilhados com mais nada) RAID-1 ou RAID-10. Logicamente, você pode ver o processo como o DBMS principal gravando entradas de log e um ou mais threads de leitor de log que consomem os logs e gravam as alterações nos discos de dados (na prática, o processo é otimizado para que as gravações de dados sejam gravadas imediatamente quando possível). Se houver outro tráfego nos discos de log, as cabeças serão movidas por esses outros acessos e as gravações de log sequenciais se tornarão gravações de log aleatórias. Eles são muito mais lentos, portanto, discos de log ocupados podem criar um ponto de acesso que atua como um gargalo em todo o sistema.

Gravações de dados

(atualizado) As gravações de log devem ser confirmadas no disco (conhecido como mídia estável) para que uma transação seja válida e qualificada para confirmação. É possível ver isso logicamente como entradas de log sendo gravadas e, em seguida, usadas como instruções para gravar páginas de dados no disco por um processo assíncrono. Na prática, as gravações de página de disco são realmente preparadas e armazenadas em buffer no momento em que a entrada de log é feita, mas não precisam ser gravadas imediatamente para que a transação seja confirmada. Os buffers de disco são gravados em mídia estável (disco) pelo processo Lazy Writer (Obrigado a Paul Randal por apontar isso) que Este artigo Technet discute um pouco mais detalhadamente.

Este é um padrão de acesso altamente aleatório, portanto, compartilhar os mesmos discos físicos com logs pode criar um gargalo artificial no desempenho do sistema. As entradas de log devem ser gravadas para que a transação seja confirmada, então ter buscas aleatórias retardando esse processo (I/O aleatório é muito mais lento do que I/O de log sequencial) irá transformar o log de um dispositivo de acesso sequencial em um dispositivo de acesso aleatório. Isso cria um sério gargalo de desempenho em um sistema ocupado e deve ser evitado. O mesmo se aplica ao compartilhar áreas temporárias com volumes de log.

A função do cache

Os controladores SAN tendem a ter grandes caches RAM caches, que podem absorver o tráfego de acesso aleatório até certo ponto. No entanto, para integridade transacional, é desejável ter gravações em disco de um DBMS com garantia de conclusão. um controlador é configurado para usar cache de write-back, os blocos sujos são armazenados em cache e a chamada de E/S é relatada como concluída ao Host.

Isso pode amenizar muitos problemas de contenção, pois o cache pode absorver muita E/S que, de outra forma, iria para o disco físico. Ele também pode otimizar as leituras e gravações de paridade para RAID-5, o que diminui o efeito sobre o desempenho dos volumes RAID-5.

Estas são as características que impulsionam a escola de pensamento 'Deixe o SAN lidar com isso', embora esta visão tenha algumas limitações:

  • O cache write-back ainda tem modos de falha que podem perder dados, e o controlador mentiu para o DBMS, dizendo que os blocos foram gravados no disco onde de fato não foram. Por esse motivo, você pode não querer usar o cache de write-back para um aplicativo transacional, especialmente algo que contenha dados de missão crítica ou financeiros onde problemas de integridade de dados podem ter sérias consequências para os negócios.

  • O SQL Server (em particular) usa E/S em um modo em que um sinalizador (denominado FUA ou Acesso de atualização forçada) força gravações físicas no disco antes que a chamada retorne. A Microsoft tem um programa de certificação e muitos SAN fornecedores produzem hardware que respeita essas semânticas (requisitos resumidos aqui ). Neste caso, nenhuma quantidade de o cache otimizará as gravações em disco, o que significa que o tráfego de log irá será interrompido se estiver em um volume compartilhado ocupado.

  • Se o aplicativo gerar muito tráfego de disco, seu conjunto de trabalho pode saturar o cache, o que também causará problemas de contenção de gravação.

  • Se o SAN for compartilhado com outros aplicativos (particularmente no mesmo volume de disco), o tráfego de outros aplicativos pode gerar gargalos de log.

  • Alguns aplicativos (por exemplo, data warehouses) geram grandes picos de carga transitória que os tornam bastante anti-sociais em SANs.

Mesmo em um grande SAN volumes de log separados ainda são uma prática recomendada. Você pode se safar sem se preocupar com o layout de um aplicativo pouco usado. Em aplicativos realmente grandes, você pode até obter o benefício de vários SAN. A Oracle publica uma série de estudos de caso de layout de data warehouse em que algumas das configurações maiores envolvem vários controladores.

Coloque a responsabilidade pelo desempenho onde ela pertence

Em algo com grandes volumes ou onde o desempenho pode ser um problema, faça a SAN equipe responsável pelo desempenho do aplicativo. Se eles vão ignorar suas recomendações de configuração, certifique-se de que o gerenciamento estão cientes disso e de que a responsabilidade pelo desempenho do sistema está no lugar apropriado.Em particular, estabeleça diretrizes aceitáveis ​​para estatísticas de desempenho do banco de dados, como esperas de E/S ou esperas de travamento de página ou SLAs de E/S de aplicativos aceitáveis.

Observe que ter a responsabilidade pelo desempenho dividida entre várias equipes cria um incentivo para apontar o dedo e passar a responsabilidade para a outra equipe. Este é um conhecido antipadrão de gerenciamento e uma fórmula para problemas que se arrastam por meses ou anos sem nunca serem resolvidos. Idealmente, deve haver um único arquiteto com autoridade para especificar o aplicativo, banco de dados e SAN alterações de configuração.

Além disso, compare o sistema sob carga. Se você puder providenciar, servidores de segunda mão e arrays de conexão direta podem ser comprados por um preço bastante baixo no Ebay. Se você configurar uma caixa como esta com uma ou duas matrizes de disco, você pode fracionar com a configuração do disco físico e medir o efeito no desempenho.

Como exemplo, fiz uma comparação entre um aplicativo executado em um grande SAN (um IBM Shark) e uma caixa de dois soquetes com uma matriz U320 de conexão direta. Neste caso, £ 3.000 o valor do hardware adquirido no ebay superou o valor de £ 1M high-end SAN por um fator de dois - em um Host com CPU e configuração de memória aproximadamente equivalente).

A partir desse incidente em particular, pode-se argumentar que ter algo assim por aí é uma boa maneira de manter os administradores SAN honestos).

37
ConcernedOfTunbridgeWells

Estou assumindo que a tag Equallogic e o conteúdo da solicitação significam que você está falando sobre um SAN Equallogic. O que se segue é especificamente sobre Equallogic e não se aplica a outros tipos SAN.

Com os arrays Equallogic, os discos específicos usados ​​para volumes não podem ser especificados com a mesma precisão com que, digamos, os arrays EMC Clariion, a abordagem deve ser um pouco diferente.

A arquitetura Equallogic é muito automatizada e dinâmica. Seu bloco de construção básico é a unidade de array, não pacotes\grupos RAID em um array, como visto em outras SANs. Cada array é totalmente configurado para RAID 5, 6, 10 ou 50, embora isso não implique que haja apenas um grupo RAID por array, você nunca consegue decidir ou interagir com eles nesse nível. Você coloca arrays em pools de armazenamento e seus pools pertencem a um grupo de armazenamento. O grupo de armazenamento tem um cluster\endereço IP virtual que você usa como o destino iSCSI Discovery para todos os volumes dentro desse grupo - o software de gerenciamento do Grupo EQL e a pilha Host MPIO lida com o redirecionamento de nível de IP necessário para realmente rotear para a porta mais apropriada em os arrays individuais ao solicitar blocos de dados, mas isso é algo que você tem pouca ou nenhuma capacidade de controlar.

Os volumes de armazenamento são atribuídos a partir do espaço livre total em cada pool. Todos os volumes dentro de um pool são espalhados por todos os arrays naquele pool (bem até um máximo de 4 arrays separados) para distribuir rede IO pelo número total de interfaces de rede (2-4 por matriz Eql dependendo do modelo) e IO em tantos controladores quanto possível. O software de gerenciamento Equallogic monitora o desempenho do volume\matriz ao longo do tempo e otimiza dinamicamente a distribuição de blocos nas matrizes membros. a menos que você saiba o que está fazendo, você deve colocar todos os arrays em um único pool e deixá-lo fazer seu trabalho apenas lembre-se de configurar seus discos de alta velocidade (SAS 10k\15k) com RAID 10, velocidade média com RAID 50 ou 5 para garantir que o processo de otimização realmente escolha as unidades de alto desempenho reais. Pode levar alguns dias (7 +) para realmente chegar a um estado ideal, mas em geral deve atingir uma distribuição equilibrada muito rápido, pois distribui imediatamente os volumes sobre tantos arrays quanto puder (novamente até o 4) quando são inicialmente criados.

Em uma estimativa aproximada, você terá algo entre 2500-5000 IOPs por matriz PS, dependendo do tipo de unidade e do tipo RAID. Se você fornecer IOPs totais suficientes, o processo de gerenciamento automatizado deverá, eventualmente, fornecer um bom desempenho, mesmo se você simplesmente agrupar todos os volumes em um único pool.

No entanto, se você quiser garantir que seus logs, bancos de dados, armazenamentos temporários, unidades de sistema operacional, etc., estejam realmente isolados uns dos outros, você pode fazer algumas coisas. Em primeiro lugar, você pode definir uma preferência de RAID para um volume que garantirá que o volume específico seja sempre armazenado apenas em matrizes desse tipo de RAID (se estiverem presentes no pool ao qual o volume pertence). Em segundo lugar, você pode definir pools de armazenamento em camadas que contêm apenas arrays que oferecem os vários graus de desempenho necessários para aquela camada específica e, em seguida, distribuir seus volumes nos pools apropriados. O aviso de integridade que vem com essa abordagem é que você geralmente precisará de muitos arrays para que isso realmente entregue um melhor desempenho geral - o que pode ser menos importante para você do que garantir o desempenho em seus volumes críticos, portanto, muitas vezes ainda é o melhor escolha. A arquitetura de referência da Dell para bancos de dados Oracle usa um pool com 2 matrizes RAID 10 para dados, disco de votação e OCR, e um pool separado com uma única matriz RAID 5 para a área de recuperação Flash.

Em todos os pontos no tempo com Equallogic, você deve se perguntar se as decisões que está tomando em relação ao particionamento forçado vão fornecer melhor desempenho agregado para seus volumes em termos de interfaces de rede disponíveis, eixos de disco e controladores. Se não souber responder, opte pelo número mínimo de piscinas e deixe-o cuidar dos detalhes ou peça a um especialista da Equallogic para fazer um design real. Se você tiver apenas um array, não há nada que possa fazer em termos de separação de volumes.

9
Helvick

Armazenamos nossos bancos de dados em caixas únicas SAN, mas com dados separados, log e LUNs de backup, cada um em grupos de discos diferentes, em camadas por velocidade - com nossos logs em RAID 10 LUNs de 15 Krpm, dados em RAID 1 10/15 krpm LUNs e backup em RAID 5 7,2 krpm LUNs. Também apresentamos registros e dados por meio de controladores diferentes no mesmo SAN.

5
Chopper3

Ótima pergunta!

Primeiro, dê uma olhada no debate "Steel Cage BlogMatch" de Brent Ozar sobre esse assunto.

Em nossa empresa, para a maioria dos servidores, colocamos Dados e Logs na mesma unidade SAN drive, e deixamos isso para a equipe SAN para garantir que tudo funcione certo.

Estou começando a achar que essa não é a melhor estratégia, especialmente para servidores de alto volume. O problema subjacente é que eu realmente não tenho como verificar se a equipe SAN equipe está realmente fazendo algo mais do que juntar drives suficientes para o espaço de que precisamos. Não executamos IO benchmarks contra os SAN drives de nosso lado ou qualquer coisa, nós meio que presumimos que eles estão "fazendo seu trabalho" (ajustando para desempenho, bem como espaço), que provavelmente é um pouco ingênuo.

Meu outro pensamento é que o tipo de acesso que os dados e os logs precisam é diferente. Vou tentar encontrar o artigo que li recentemente que falava sobre como os dois tipos diferentes de drives realmente deveriam ser otimizados de maneiras muito diferentes (acho que um precisava de otimização para gravações sequenciais, o outro precisava de otimização para leituras aleatórias, algo assim .)

4
BradC

Resumindo, sim, você criaria volumes separados para arquivos de dados do SQL Server, arquivos de log e dados TempDB e arquivos de log.

Como você marcou sua pergunta com Equallogic, leia o gratuito Guia de arquitetura de referência da Dell: Implantando o Microsoft® SQL Server® com matrizes de armazenamento Dell ™ EqualLogic ™ série PS50 (requer registro) antes de projetar sua solução. Freqüentemente, você descobrirá que a orientação sobre configurações específicas pode diferir significativamente da orientação genérica .

4
Peter Stuer

Eu concordaria com BradC (+1) em termos de desempenho. Geralmente, um bom SAN teria mais E/S bruta do que você poderia esperar usar.

Ainda é uma boa ideia separar seus BACKUPs do seu sistema ativo (óbvio eu sei, mas se eu ganhasse £ 1 para cada vez que vejo isso ...)

Além disso, é recomendável manter o tempdb longe dos arquivos de log. O SAN tenda do cara para rolar os olhos para você quando você começar a querer "baldes diferentes" (termo técnico) para registros, dados e temperatura, mas se você disser a eles é para que você possa avaliar os diferentes quantidade de dados IO indo para cada área e fazer com que mostrem seus gráficos de desempenho sofisticados!

Apenas verifique se o SAN cara configurou corretamente para você. Se você quiser RAID 10, então insista nele (eu fiz) mesmo que eles continuem dizendo que o RAID 5 não tem desempenho pena.

(Para operações "baseadas em arquivo", RAID 5 é adequado. Para gravações intensivas, assim que você preencher o buffer de gravação, você se ferrou!)

3
Guy

Esteja ciente de todas as combinações de termos aqui também.

Geralmente e muito básico:

  • Array = um conjunto de discos em uma configuração RAID (como RAID5)
  • Volume = uma parte de um array apresentado ao Host no SAN com um LUN

Você pode ter vários volumes no mesmo array, o que é algo para se lembrar quando você estiver fazendo otimizações de alto grau discutidas neste tópico.

A chave é o que vários outros mencionaram (não se esqueça), separe os dados/log/backup em diferentes eixos de unidade, não apenas em volumes separados.

Edit: e Helvick acima deu-lhe uma -ótima- resposta sobre SANs Equallogic!

2
pauska