Em 14/04/08, Welington R. Braga<[EMAIL PROTECTED]> escreveu: > 2. Storages podem trabalhar em três modos diferentes, dependendo do seu > modelo e que devem ser escolhidos de acordo com a topologia desejada: DAS, > SAN, NAS (A ordem em que os coloquei reflete o meu ponto de vista com > relação a performance e também ao preço). É isso mesmo? >
A performance entre DAS e SAN não é diferente. Não existe switch DAS e switch SAN, o storage é o mesmo. O que existem são gavetas de discos criadas para NAS que tem o nome de DAS. O delay introduzido por um swith é quase irrelevante, pelo menos no caso do fibre Channel. Se você estiver preocupado com desempenho, o nó está em se escolher iSCSI ou fibre Channel. Outra coisa é a quantidade de discos e o tipo de RAID que você vai utilizar. Mas um detalhe são quantas HBAs você vai utilizar. Você pode utilizar até 4 HBAs num único servidor por storage. Assim você pode determinar que 2 HBAs vão acessar um determinado grupo de discos específicos e deixar outro grupo de discos para as outras 2 HBAs. Veja que mesmo com 4 HBAs num único servidor, você ainda pode escolher entre DAS e SAN. Um storage tem normalmente pelo menos 4 portas de saída. O NAS é utilizado apenas como servidor de arquivos. Você pode utilizar um NAS para guardar seus backups do banco, mas é só. O NAS não tem o desempenho satisfatório para um banco de dados, mas é uma opção excelente para compartilhar arquivos na rede. A vantagem do NAS como servidor de arquivos é a centralização de serviços, baixo custo, segurança (você tem quase sempre a opção de usar um RAID) e a capacidade de expansão (alguns NAS podem ser empilhaveis) para dezenas de discos. Um NAS pode ser plugado na sua LAN e já sai funcionando, um Storage em DAS ou SAN funciona em um esquema completamente isolado da sua rede. Você pode até mesmo montar servidores de aplicação sem discos locais e dar o boot neles a partir de um NAS. No DAS ou SAN os discos aparecem para o servidor como discos locais, não usam um esquema de compartilhamento como SMB ou NFS, que é o caso do NAS. A configuração de um NAS é semelhante a configuração de um compartilhamento de arquivos que você faz no seu próprio desktop. Já num Storage em DAS ou SAN, os servidores reconhecem os discos como se fossem dispositivos locais e para compartilhar um grupo de discos entre vários servidores, você vai precisar de um sistema de arquivos de cluster como o CFS ou OCFS2, que é algo bem mais complexo de se configurar e exige sincronização constante entre os servidores envolvidos. > 3. Ainda quanto aos modos NAS, SAN ou DAS: > 3.1 Os storages que trabalham como "NAS" nada mais são do que servidores de > arquivos que possuem um número relativamente maior que o normal - ou não - > de interfaces SCSI, SATA etc para colocar vários discos em RAID e a partir > daí é "só colocar o bicho na rede" e acessá-lo via protocolos comuns tal > como CIFS/SMB, FTP, NFS, SSHFS entre outros. Um sotrage deste tipo > trabalhando placas de fibra teria uma performance "teoricamente" similar ou > bem cróxima a de um storage tipo "SAN". Inclusive há um projeto chamado > FreeNAS cujo objetivo é usar uma distribuição FreeBSD[1] para gerenciar um > servidor especialmente preparado para este fim. > Não é bem assim. Os Storages são equipamentos dedicados. Eles possuem a capacidade de empilhar uma grande quantidade de discos adicionando novas gavetas de discos. O hardware é customizado, particulamente as controladoras de discos são bem diferentes das que você encontrará a venda. Assim, a performance de um NAS costuma ser bem inferior. É uma caixa preta bastante customizada. Se você for montar um Storage iSCSI para servir como servidor de arquivos, você mesmo pode montar um. Mas em bancos de dados onde o desempenho e segurança valem a pena o investimento, os storages fibre channel ainda são a melhor opção. Storages fibre Channel são proprietários até no parafuso do rack onde eles ficam. A questão de você ter uma SAN é uma opção sua. Se apenas um ou dois servidores vão acessar o Storage, você pode usar o DAS e ligar o(s) servidor(es) direto no storage. Se você tem mais de um servidor acessando o storage você monta uma rede separada que pode ser uma gigabit (no caso do iSCSI) ou fibre channel. Não existe nenhum problema em começar com um esquema DAS e depois passar para uma SAN. Uma SAN fibre channel é cara, pois os switches são bem salgados. Mas se você se preocupa com alta disponibilidade e tiver um cluster de banco de dados, a SAN é a sua única opção. Lembre-se que a SAN é uma rede separada. Hoje você tem: - a DMZ (para interconectar os seus servidores), - a SAN (para conectar os servidores no Storage), - a BAN (para conectar os servidores no robô de backup) e - a LAN (para os mortais que vão acessar os servidores). > 3.3 Além de melhores (com relação a performance) e mais caros, os storages > "DAS" são conectados diretamente ao servidor, então eles precisam de uma > interface especial no servidor e são independentes de uma rede. Mas o número > de servidores estará limitado ao número de portas disponíveis neste > equipamento. Estou certo? Além do preço deste equipamento ser elevado parce > que vou ficar "amarrado" a determinado fabricante para aquisição de novas > placas para outros servidores. O storage não muda, o que muda é como o(s) servidor(es) vão chegar até ele. > > 4. É necessário na hora de elaborar o edital para licitação que eu amarre o > swicth e as placas HBA ao storage a ser adquirido. Você só precisa especificar com detalhes a tecnologia que vai utilizar. Você pode ter diferentes fornecedores de HBA, switch e storage. Mais é só. Não esqueça de licitar o suporte!!! A configuração inicial do conjunto não é trivial e pode dar muita dor de cabeça. Você vai precisar da ajuda de alguém. Você precisa especificar: - Em qual tipo de servidor a HBA vai ser instalada e qual software (linux, kernel, 32 bits ou 64 bits). Quantas HBAs serão adquiridas? - Qual é o tipo de rede que vai ser utilizado, vai ser uma SAN ou DAS? Vai ser iSCSI ou fibre Channel? Qual a velocidade? A rede deve ser a mesma para as HBAs, switches e storages. - O storage deve ter suporte a mais de um tipo de discos? Quais raids devem ser suportados? Qual o tamanho (18GB, 36GB, 72GB, 146GB, 300GB...), velocidade dos discos(7200, 10K, 15K), tipo (SAS, SATA, SCSI, fibre Channel) suportados. Qual é quantidade máxima de discos que o storage suporta? - Pense com cuidado nos discos que vão ser comprados na licitação e nos discos que serão comprados futuramente. Em 3 anos você pode começar a ter dificuldades em achar discos para o seu Storage no mercado, ou eles podem ser incompatíveis com os discos utilizados em seus novos storages. - Qual é o período que o fabricante oferece para o suporte a aquele modelo de storage? Alguns modelos podem estar para sair de linha e ter um período curto de suporte oficial. Peça a garantia de pelo menos 5 anos de suporte disponível para o modelo adquirido (mesmo que você não o tenho comprado naquele momento). - Especifique na licitação qual é a garantia do equipamento. 3 anos é o default, mas você pode comprar já com um período maior. Especifique também os termos da garantia. Inclui monitoramento remoto? Inclui a troca de qualquer peça, incluindo os discos? Qual é o tempo para a troca de um componente defeituoso? - Especifique serviços adicionais que você pode querer contratar como tuning do storage, suporte remoto ou presencial, etc. - Fique de olho nas licenças de software. Você pode comprar um excelente storage mas não ter acesso a toda a sua capacidade. Há softwares adicionais que são licenciados separadamente, particulamente softwares para tuning e snapshots e gerenciamento avançado. Especifique o tipo de software que deve vir incluso no pacote, conheça as opções dos fornecedores. Elas em geral são bastante parecidas então você precisa especificar as suas características genéricas no edita. > > 5. Entre FibreChannel e iSCSI a primeira opção é a que tem melhor > performance e a segunda está tornando-se obsoleta. Certo? > O iSCSI não é obsoleto, muito pelo contrário, tem crescido muito. Alguns acreditam que em breve o iSCSI vai alcançar a mesma performance do Fibre Channel, mas isso ainda não aconteceu. Há algumas implementações de iSCSI de baixo custo que usam NICs ethernet gigabit ao invés de uma HBA dedicada. Se você fizer isso terá uma performance bem pior. Mas o iSCSI está melhorando, vale a pena ficar de olho neste mercado que tem crecido muito. Mas por enquanto, os bancos de dados ainda gostam mais do Fibre Channel. > 6. Por dedução e também pela opinião de alguns colegas que responderam este > tópico, com respeito aos serviços que utilizo (já citados no meu primeiro > e-mail), parece que pro meu caso um SAN teria o melhor custo/benefício. > Isto depende do número de servidores que vão acessar o storage. Não faz nenhum sentido gastar dinheiro com switches se apenas um ou dois servidores vão acessar o storage. É claro que existem equipamentos dedicados de DAS, em geral são como frames para um NAS. Não é deles que estou falando, e sim da forma como o seu servidor vai se conectar ao storage. Genericamente, quando falamos de Storage não estamos falando de NAS. > 7. Quanto a distribuição Debian a conclusão que cheguei foi a mesma que já > tinha desde o começo... vou ter problemas para arrumar HBA compatíveis com > ele. Alguém sugere uma que funcione? Como diz um amigo meu... Linux é linux!!! Mas seria bom especificar no edital qual distribuição você vai usar, só para não ter que ficar ouvindo besteira. Mas que funciona, funciona. > > 8. Não entendi a questão da complexidade em se fazer backups que alguns > comentaram. Eu não poderia usar o Bacula[2] ou o Amanda[3] para realizar > backup dos dados como é feito atualmente? Entendo que se fizesse diretamente > pelo storage isso seria mais rápido, mas velocidade de backup ainda não > minha preocupação. > A melhor coisa dos bons storages em relação ao backup é poder fazer snapshot. Quem usa storages em bancos de dados, geralmente não tem bases pequenas. Com bases maiores que alguns GBs, o backup lógico se torna apenas complementar. O importante mesmo é copiar todos os arquivos do banco de dados. Esta operação é crítica e o storage permite fazer isso rapidamente, se você tiver comprado a licença do software que faz isso. Assim, você tem um backup realizado rapidamente, sem afetar a operação em produção e um tempo de recuperação também muito bom. *** Vale a pena relembrar: backp lógico (feito com pgdump) não serve para recuperação de desastres, pois demora uma eternidade para restaurar um. > 9. O NetApp não tem frescuras com licenciamento e restrição do número de > LUNs, ou hosts etc. O que acontece nos da IBM e EMC. > No EMC e no Hitachi, tem frescuras quanto aos softwares licenciados. Mas número de LUNs eu acho que não. Bom, eu acho que é isso. Atenciosamente, Fábio Telles -- blog: http://www.midstorm.org/~telles/ e-mail / jabber: [EMAIL PROTECTED] _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
