Sua prática padrão de separar arquivos de log e dados para separar os discos do SO (tempdb, backups e arquivo de troca também) Essa lógica ainda faz sentido quando suas unidades são todas baseadas em SAN e seus LUNS não são esculpidos em conjuntos específicos de discos ou raides -eles são apenas parte do número x de unidades na SAN e o LUN é apenas alocação de espaço
Respostas:
Logs e unidades de dados têm diferentes padrões de acesso a dados 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 número muito grande de pequenas gravações seqüenciais. De maneira um pouco simplista, os logs do banco de dados são buffers de anel que contêm 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 seqüenciais que devem ser garantidas para serem concluídas - para que sejam gravadas no disco.
Idealmente, os logs devem estar em um volume RAID-1 ou RAID-10 silencioso (ou seja, não compartilhado com mais nada). Logicamente, é possível visualizar o processo como o DBMS principal que grava entradas de log e um ou mais encadeamentos de leitores de log que consomem os logs e grava 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 seqüenciais de log se tornarão gravações aleatórias. Como são muito mais lentos, os 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 visualizar 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 da página do disco são realmente preparadas e armazenadas em buffer no momento em que a entrada do log é feita, mas elas 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 (Agradecimentos a Paul Randal por apontar isso), que este artigo da Technet discute com mais detalhes.
Esse é um padrão de acesso fortemente aleatório, portanto, o compartilhamento dos mesmos discos físicos com logs pode criar um gargalo artificial no desempenho do sistema. As entradas do log devem ser gravadas para que a transação seja confirmada; portanto, ter buscas aleatórias que atrasam esse processo (a E / S aleatória é muito mais lenta que a E / S de log seqüencial) transformará o log de um sequenital 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.
O papel do cache
Os controladores SAN tendem a ter grandes caches de RAM, que podem absorver o tráfego de acesso aleatório até certo ponto. No entanto, para integridade transacional, é desejável que as gravações em disco de um DBMS garantam a conclusão. Quando um controlador é configurado para usar o cache de write-back, os blocos sujos são armazenados em cache e a chamada de E / S é relatada como concluída para o host.
Isso pode atenuar muitos problemas de contenção, pois o cache pode absorver muitas E / S que seriam enviadas para o disco físico. Também pode otimizar a leitura e gravação de paridade para RAID-5, o que diminui o efeito no desempenho dos volumes RAID-5.
Essas são as características que orientam a escola de pensamento 'Deixe a SAN lidar com isso', embora essa visão tenha algumas limitações:
O cache de write-back ainda possui modos de falha que podem perder dados, e o controlador falsificou o DBMS, dizendo que os blocos foram gravados no disco onde, na verdade, não existem. Por esse motivo, talvez você não queira usar o cache de write-back para um aplicativo transacional, principalmente algo que contenha dados financeiros ou de missão crítica, onde os problemas de integridade de dados podem ter sérias conseqüências para os negócios.
O SQL Server (em particular) usa E / S em um modo em que um sinalizador (chamado FUA ou Forced Update Access) força gravações físicas no disco antes do retorno da chamada. A Microsoft possui um programa de certificação e muitos fornecedores de SAN produzem hardware que respeita essas semânticas (requisitos resumidos aqui ). Nesse caso, nenhuma quantidade de cache otimizará as gravações em disco, o que significa que o tráfego do log será afetado se estiver em um volume compartilhado ocupado.
Se o aplicativo gerar muito tráfego de disco, seu conjunto de trabalho poderá sobrecarregar o cache, o que também causará problemas de contenção de gravação.
Se a SAN for compartilhada com outros aplicativos (particularmente no mesmo volume de disco), o tráfego de outros aplicativos poderá gerar gargalos de log.
Alguns aplicativos (por exemplo, data warehouses) geram grandes picos de carga transitória que os tornam bastante anti-sociais nas SANs.
Mesmo em uma grande SAN, volumes de log separados ainda são uma prática recomendada. Você pode não se preocupar com o layout de um aplicativo pouco usado. Em aplicativos realmente grandes, você pode até se beneficiar de vários controladores 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 ele pertence
Em algo com grandes volumes ou onde o desempenho possa ser um problema, torne a equipe da SAN responsável pelo desempenho do aplicativo. Se eles vão ignorar suas recomendações de configuração, verifique se o gerenciamento está ciente disso e que a responsabilidade pelo desempenho do sistema está no local apropriado. Em particular, estabeleça diretrizes aceitáveis para as principais estatísticas de desempenho do banco de dados, como espera de E / S ou espera de trava de página ou SLAs de E / S de aplicativos aceitáveis.
Observe que a responsabilidade pelo desempenho dividido em várias equipes cria um incentivo para apontar o dedo e passar o dinheiro para a outra equipe. Esse é um anti-padrão de gerenciamento conhecido e uma fórmula para problemas que se prolongam por meses ou anos sem nunca serem resolvidos. Idealmente, deve haver um único arquiteto com autoridade para especificar alterações de aplicativo, banco de dados e configuração da SAN.
Além disso, avalie o sistema sob carga. Se você puder organizá-lo, os servidores de segunda mão e as matrizes de conexão direta podem ser adquiridos com muito mais barato no Ebay. Se você configurar uma caixa como esta com uma ou duas matrizes de disco, poderá executar a configuração do disco físico e medir o efeito no desempenho.
Como exemplo, fiz uma comparação entre um aplicativo em execução em uma grande SAN (um IBM Shark) e uma caixa de dois soquetes com uma matriz U320 de conexão direta. Nesse caso, £ 3.000 em hardware comprado no ebay superaram uma SAN high-end de £ 1 milhão por um fator de dois - em um host com CPU e configuração de memória aproximadamente equivalentes.
A partir desse incidente específico, pode-se argumentar que ter algo assim por aí é uma maneira muito boa de manter os administradores da SAN honestos.
Suponho que a tag Equallogic e o conteúdo da solicitação signifiquem que você está reclamando de uma SAN Equallogic. O que segue é especificamente sobre o Equallogic e não se aplica a outros tipos de SAN.
Com matrizes Equallogic, os discos específicos usados para volumes não podem ser especificados com a maior precisão possível, digamos, com as matrizes EMC Clariion, portanto a abordagem deve ser um pouco diferente.
A arquitetura equallogic é muito automatizada e dinâmica. Seu componente básico é a unidade da matriz, não os pacotes e grupos de RAID dentro de uma matriz, como visto em outras SANs. Cada matriz é totalmente configurada para RAID 5, 6, 10 ou 50, embora isso não implique que exista apenas um grupo RAID por matriz, você nunca decide ou interage com eles nesse nível. Você coloca matrizes em conjuntos de armazenamento e seus conjuntos pertencem a um grupo de armazenamento. O Storage Group possui um endereço IP cluster \ virtual que você usa como destino de descoberta iSCSI para todos os volumes desse grupo - o software de gerenciamento do Grupo EQL e a pilha MPIO do host lida com o redirecionamento de nível de ip necessário para realmente rotear para a porta mais apropriada em as matrizes 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 em um pool estão espalhados por todas as matrizes desse pool (até um máximo de 4 matrizes separadas) para distribuir a E / S de rede pelo número total de interfaces de rede (2-4 por matriz Eql, dependendo do modelo) e E / S através do maior número possível de controladores. 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 de membros. Em geral, a menos que você saiba o que está fazendo, você deve colocar todas as matrizes em um único pool e deixar isso funcionar; lembre-se de garantir que você configure 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 reais de alto desempenho.
Para uma aproximação aproximada, você terá entre 2500-5000 IOPs por array PS, dependendo do tipo de unidade e do tipo RAID. Se você fornecer IOPs totais suficientes, o processo de gerenciamento automatizado deverá 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 SO etc. sejam realmente isolados um do outro, você poderá fazer algumas coisas. Primeiro, você pode definir uma preferência de RAID para um volume que garanta 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 conjuntos de armazenamento em camadas que contêm apenas matrizes que oferecem os vários graus de desempenho necessários para esse nível específico e depois distribuir seus volumes nos conjuntos apropriados. O aviso de integridade que vem com essa abordagem é que você geralmente precisará de muitas matrizes para que isso realmente ofereça melhor desempenho geral - que pode ser menos importante para você do que garantir o desempenho em seus volumes críticos, embora ainda seja frequentemente o melhor escolha. A arquitetura de referência da Dell para Oracle DBs 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 de flash.
Em todos os momentos do Equallogic, você deve se perguntar se as decisões que você está tomando em relação ao particionamento forçado fornecerão melhor desempenho agregado para seus volumes em termos de interfaces de rede disponíveis, eixos de disco e controladores. Se você não puder responder, opte pelo número mínimo de piscinas e deixe-o lidar com os detalhes ou procure um especialista em Equallogic para fazer um design real. Se você tiver apenas uma matriz, não poderá fazer nada em termos de separação de volumes.
Armazenamos nossos bancos de dados em caixas SAN únicas, mas com dados separados, LUNs de log e backup, cada um em diferentes grupos de discos, em camadas por velocidade - com nossos registros em LUNs RAID 10 de 15Krpm, dados em LUNs RAID 1 10 / 15krpm e backup em RAID 5 LUNs de 7.2 krpm. Também apresentamos logs e dados através de diferentes controladores na mesma SAN.
Ótima pergunta!
Primeiro, dê uma olhada no debate "Steel Cage BlogMatch" de Brent Ozar sobre esta questão.
Em nossa empresa, para a maioria dos servidores, colocamos Dados e Logs na mesma unidade SAN e deixamos para a equipe da SAN garantir que tudo funcione corretamente.
Estou começando a pensar que essa não é a melhor estratégia, especialmente para servidores de maior volume. O problema subjacente é que eu realmente não tenho como verificar se a equipe da SAN está realmente fazendo algo além de juntar unidades suficientes para o espaço que precisamos. Nós não executamos benchmarks de IO nas unidades SAN do nosso lado ou qualquer coisa do tipo, apenas assumimos que eles estão "fazendo seu trabalho" (ajustando o desempenho e o espaço), o que provavelmente é um pouco ingênuo.
Meu outro pensamento é que o tipo de acesso que os dados vs logs precisam é diferente. Vou tentar encontrar o artigo que li recentemente que estava falando sobre como os dois tipos de unidades diferentes 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 .)
Em resumo, sim, você criaria volumes separados para arquivos de dados, arquivos de log e arquivos de dados e log TempDB do SQL Server.
Como você marcou sua pergunta com o Equallogic, leia o Dell Reference Architecture Guide gratuito : Implantando o Microsoft® SQL Server® com matrizes de armazenamento Dell ™ EqualLogic ™ PS5000 Series (registro obrigatório) antes de projetar sua solução. Frequentemente, você encontrará orientações sobre configurações específicas que podem diferir significativamente dos conselhos genéricos .
Eu concordo com BradC (+1) em termos de desempenho. Geralmente, uma boa SAN teria mais E / S bruta do que você poderia esperar usar.
Ainda é uma boa idéia separar seus BACKUPs do seu sistema ativo (é óbvio, eu sei, mas se eu tivesse 1 libra por cada vez que vejo isso ...)
Além disso, é recomendável manter o tempdb longe dos arquivos de log. A barraca do cara da SAN para revirar os olhos para você quando você começa a querer "baldes diferentes" (termo técnico) para Logs, Dados e Temp. faça com que eles mostrem seus gráficos de desempenho sofisticados!
Apenas verifique duas vezes / duas vezes se o pessoal da SAN a configurou corretamente para você. Se você quiser o RAID 10, insista (eu fiz), mesmo que eles continuem dizendo que o RAID 5 não tem penalidade de desempenho.
(Para operações "baseadas em arquivos", o RAID 5 é bom. Para gravações intensivas, assim que você preenche o buffer de gravação, está ferrado!)
Esteja ciente de toda a mistura de termos aqui também.
Geralmente, e muito básico:
Você pode ter vários volumes na mesma matriz, algo que deve ser lembrado quando você estiver fazendo otimizações de alto nível discutidas neste segmento.
A chave é o que vários outros mencionaram (não esqueça), separe os dados / log / backup em diferentes eixos de unidades, e não apenas volumes separados.
Edit: e Helvick acima deu uma ótima resposta sobre SANs Equallogic!