iSCSI para bancos de dados, boa ideia

7

É uma boa ideia ter um banco de dados transacional em execução em um servidor que usa iSCSI?

O principal argumento é que você pode ter dois servidores acessando a mesma matriz de disco, portanto, se um servidor quebrar, o outro poderá efetuar o trabalho.

Então eu tenho um servidor em algum modo de espera a frio. Essa configuração é realmente mais segura do que ter discos e servidores na mesma máquina?

Isso significaria que as máquinas iSCSI não quebram tão facilmente quanto um servidor.

Outro ponto é o WAL, que pode ser afetado negativamente se a rede estiver atrasada. Alguma experiência?

Fico feliz em saber que você tem opiniões sobre esse assunto.

    
por Franz Kafka 04.06.2011 / 15:24

6 respostas

9

Sua pergunta precisa ser dividida em duas partes: armazenamento interno vs externo e iSCSI versus as alternativas (FC, FCoE, NFS). Minha experiência é com grandes clientes corporativos que executam principalmente o Oracle, portanto, isso pode não se aplicar a ambientes menores ou a outros bancos de dados. Na minha opinião, há muito valor no armazenamento externo; O iSCSI é uma opção para fornecer isso, mas não é tão maduro quanto algumas das alternativas.

Armazenamento interno vs externo

O armazenamento externo, geralmente provisionado em uma matriz de disco e apresentado por meio de uma rede de área de armazenamento (SAN), oferece várias vantagens:

  • Desempenho rápido, geralmente com RAID acelerado por hardware e grandes caches suportados por bateria.
  • Fácil de ampliar volumes para usar mais discos para desempenho e capacidade.
  • Acesso centralizado a recursos de armazenamento para evitar silos de recursos desperdiçados.
  • É possível compartilhar o armazenamento de clusters de alto desempenho ou alta disponibilidade (por exemplo, Oracle RAC).
  • Pode vir com recursos para captura instantânea e replicação de dados para sites remotos.
  • Pode vir com ferramentas de análise decentes para acompanhar o desempenho.

As principais desvantagens do armazenamento externo são a complexidade e o custo de configurar e manter a rede da área de armazenamento e os storage arrays.

iSCSI vs alternativas

O Fibre Channel é atualmente o mecanismo padrão para acessar o armazenamento externo de bancos de dados. É comum ver o SAS (Serial-Attached-SCSI) usado para dados menos críticos, mais como uma extensão para o disco interno do que como um disco em uma SAN. O ponto-chave sobre essas tecnologias é que elas são executadas em redes de armazenamento dedicadas.

Novas alternativas, como o FCoE e o iSCSI, fornecem efetivamente o mesmo protocolo que o FC e o SAS, exceto que eles são executados na Ethernet e, portanto, podem usar a mesma infraestrutura usada para a rede host-a-host. A ideia é que, ao convergir para a Ethernet, as empresas possam reduzir o custo e a complexidade de ter armazenamento externo. No entanto, ainda há dúvidas sobre se a Ethernet como um transporte fornece a velocidade e a confiabilidade das tecnologias dedicadas.

O NFS é um protocolo de nível de arquivo que também é executado pela Ethernet. Antigamente, considerava-se que tinha muita sobrecarga para bancos de dados, mas com descarregamento de hardware em adaptadores de rede mais recentes, melhores pilhas de rede do SO e suporte direto pelo banco de dados (por exemplo, o recurso NFS Direto no Oracle) também é uma opção viável para algumas empresas. O NFS é particularmente interessante porque reduz a administração envolvida no redimensionamento de volumes e também se ajusta ao modelo de armazenamento virtualizado, como o EMC VNX e o Oracle ZFS Storage.

    
por 04.06.2011 / 16:18
4

Na minha opinião , o iSCSI é menos estável de um transporte de rede de armazenamento do que o Fibre Channel ou o Fibre Channel over Ethernet. Supondo que você tenha feito as otimizações necessárias, isso deve funcionar. Ele funcionará melhor se a conexão iSCSI estiver passando por uma rede Ethernet dedicada, sem tráfego não-iSCSI para atrapalhar. Os iniciadores do ISCSI ficaram melhores ao longo dos anos e até suportam multipathing agora, se você quiser ir até lá.

Quanto à execução de um banco de dados transacional sobre o iSCSI, tenho minhas dúvidas. Um servidor em espera a frio deve ser capaz de continuar de onde o servidor ativo parou, presumindo que ele deixou os arquivos de banco de dados em um estado recuperável. Dito isso, o único caso de uso em que as redes de transporte de armazenamento dedicadas realmente brilham está nesse tipo de caso de uso "muitas pequenas transações".

No final, pela minha avaliação, ele funcionará, mas pode falhar mais catastroficamente do que usar FC ou FCoE.

    
por 04.06.2011 / 15:32
3

Você levantou alguns problemas diferentes. Primeiro, o iSCSI pode funcionar bem para um banco de dados transacional? Sim absolutamente. Mas é um sim qualificado. Você obterá melhor desempenho da fibra na maioria das implementações. Você precisa entender seus requisitos de IO para determinar se realmente precisa desse desempenho. Caso contrário, o iSCSI pode ser perfeito. Dito isso, o que às vezes acontece é que as pessoas vêem como o iSCSI é fácil de implementar, então elas são implementadas sem dar muita importância ao design. As práticas recomendadas para iSCSI são facilmente encontradas no Google, mas você deve estar pensando em como separar esse tráfego de outro tráfego (switches dedicados ou VLANs), como você pode implementar quadros gigantes, se usará MCS ou MPIO ( seu fornecedor provavelmente ditará isso para você), etc.

A segunda questão é como você vai projetar redundância para seus bancos de dados. Sim, é verdade que, se o servidor principal falhar, você poderá atribuir esses discos a outra caixa, mas eu não contaria com isso como minha solução de HA, porque você não tem a garantia de que o servidor primário em extinção deixou esses bancos de dados em boa forma. Há muitas maneiras de fazer o HA e a maioria delas funciona bem com o iSCSI, mas é preciso pensar um pouco mais nele.

    
por 04.06.2011 / 16:07
2

Usamos o armazenamento iSCSI para externo em nosso ambiente de banco de dados transacional da Oracle por anos sem problemas e excelente desempenho. O componente iSCSI não faz parte do nosso plano de redundância. Abordamos isso como outros ilustraram. Além disso, pelas razões mencionadas também, estamos migrando para o armazenamento baseado em NFS usando o DNFS da Oracle. Com o 11gR1 vimos alguns problemas que parecem não estar presentes no 11gR2. Ainda não temos usuários suficientes para ver como o desempenho realmente funcionará. Isso provavelmente acontece nas próximas semanas.

    
por 04.06.2011 / 19:12
1

Seu plano está seriamente defeituoso porque o desempenho usando iSCSI será claramente inferior ao de ter unidades locais. Além disso, existem esquemas melhores do que ter um cold standby para acessar as mesmas unidades, que também sofre com o ponto único de falha sendo a parte mais confiável - as unidades.

Eu sugiro que você use uma abordagem mais convencional, que tenha sido bem testada e comprovada para funcionar. Use discos locais em ambas as máquinas e use replicação master / slave ou master / master para fornecer sua redundância.

    
por 04.06.2011 / 15:50
1

Existem muitos conjuntos de discos SAS que permitem a conexão de vários servidores. Por exemplo, os arrays Dell MD32x0, quando configurados com controladores duplos, podem trabalhar com até quatro servidores com duas conexões redundantes por servidor ( link ).

Se você não tiver necessidade específica de criar um ambiente de SAN, nunca usou SANs antes e deseja apenas failover ativo / standby, essa será uma solução mais simples, mais fácil e mais barata.

    
por 04.06.2011 / 20:29