2015-03-05 12:44 GMT-03:00 Flavio Henrique Araque Gurgel <[email protected]>:
> Utilize NFSv4, um kernel recente, numa distribuição com suporte correto e > atualizada. > Monte o sistema de arquivos em modo síncrono. Isso foi feito. > Recentemente tem-se usado NFS em alguns storages modernos que oferecem a > montagem dessa forma, mas um bom iSCSI ainda é a melhor pedida. > Como não temos experiência com iSCSI, vamos fazer testes com ele. Se a performance-confiabilidade for superior a qualquer outra solução, vamos impor ela. 2015-03-05 13:37 GMT-03:00 Guimarães Faria Corcete DUTRA, Leandro < [email protected]>: > Não espere desempenho ou confiabilidade extremas. É administrável, > mas implica latência e acrescenta ponto de falha. A questão do desempenho nos testes se mostrou aceitável e até superou as expectativas. Mas a confiabilidade é algo crítico. Não percebemos até então problemas, mas não é o ambiente de produção, são apenas meros testes. 2015-03-05 13:56 GMT-03:00 Flavio Henrique Araque Gurgel <[email protected]>: > Nesse caso é fria instalar o diretório do cluster nesse servidor NFS, > desculpe a franqueza. > Agradeço e prefiro a franqueza. O DBA deve ter o "poder" sobre seus recursos para administrá-los > corretamente, pelo menos ele deve ter acesso a quem o tenha para poder > orientar e discutir. > Históricamente os sysAdmin do cliente não permitem, algo corroborado pelos seus superiores. O unico modo de convencer este cliente é mostrando na prática a necessidade. 2015-03-05 16:54 GMT-03:00 Roberto Mello <[email protected]>: > Fiz isso utilizando o recurso de snapshot do LVM e funcionava muito > bem, e não precisava mexer com NFS e sua latência e outros problemas. > O *storage* e o *hypervisor* ficam em servidores distintos. Como usar o LVM neste caso? Você utilizou NFS e/ou NBD? > 2) Criava um snapshot do volume, ou seja, um volume temporário onde > apenas as modificações ocupariam espaço em disco. > O recurso de *snapshot* é muito interessante para meu caso. > Nunca haverá mais que uma VM executando ao mesmo tempo. > Esses "nunca" geralmente nunca persistem. Com essa alternativa do LVM > você pode levantar quantas VMs você tiver recursos (CPU, buffers, e > espaço para os snapshot) para aguentar. > Realmente, os "nunca" muitas vezes mudam. Mas no meu caso especifico, isso não deve acontecer. A VM desliga num lugar e sobe em outro, apenas isso, dando a impressão de ter se movido. São centenas de VMs geográficamente distribuídas e, uma aplicação que controla essa mecânica toda. À época eu também utilizei isso com o OpenVZ, que cria containers no > Linux. Se não me engano o OpenVZ foi renomeado e melhorado > recentemente, a há vários tipos de containers similares disponíveis > por aí. > *Containers* são extremamente interessantes, a dupla docker + kubernetes torna administração de "fazendas" facilitada. Mas para meu caso, optamos por utilizar uma VM, pois há uma diversidade enorme de Distros e Windows que são os O.S. virtualizadores. Mesmo que fosse apenas Linux, teríamos de fazer um *container**s* diferentes para cada distro.
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
