Estatistica/Variáveis que justifique portar um serviço para o XEN
10 views
Skip to first unread message
horacio ibrahim
Dec 10, 2009, 9:37:07 AM12/10/09
to xen-br
Senhores, bom dia!
Antes adianto que a sintonia é variável e difícil de mensurar, mas pelo nosso knowhow podemos apontar abordagens que é interessante mensurar para justificar e "provar" a virtualização de alguns serviços.
Então peço ajuda dos senhores para pontuar o que eu devo analisar para que de forma númerica eu possa justificar que determinado serviço possa ser virtualizado e prever a capacidade, ou a necessidade de recursos que no ambiente virtual esse serviço irá requisitar.
*Obs.: Não quero abordar a solução, por exemplo, zabbix, nagios, groundwork, etc. Mas as variáveis por exemplo: CPU( %iowait, %user space, %kspace, etc), Ethernet, Discos (storages), FC TX. E um período razoável de análise, considerando picos de acesso.
Não estou identificando o hardware para onde irá e nem os serviços, pois o resultado é a abstração para que possa ser aplicado a ambientes distintos.
Desde já agradeço!
Ats,
Horacio Ibrahim
Antes adianto que a sintonia é variável e difícil de mensurar, mas pelo nosso knowhow podemos apontar abordagens que é interessante mensurar para justificar e "provar" a virtualização de alguns serviços.
Então peço ajuda dos senhores para pontuar o que eu devo analisar para que de forma númerica eu possa justificar que determinado serviço possa ser virtualizado e prever a capacidade, ou a necessidade de recursos que no ambiente virtual esse serviço irá requisitar.
*Obs.: Não quero abordar a solução, por exemplo, zabbix, nagios, groundwork, etc. Mas as variáveis por exemplo: CPU( %iowait, %user space, %kspace, etc), Ethernet, Discos (storages), FC TX. E um período razoável de análise, considerando picos de acesso.
Não estou identificando o hardware para onde irá e nem os serviços, pois o resultado é a abstração para que possa ser aplicado a ambientes distintos.
Desde já agradeço!
Ats,
Horacio Ibrahim
Reinaldo de Carvalho
Dec 10, 2009, 1:48:30 PM12/10/09
to xen...@googlegroups.com
2009/12/10 horacio ibrahim <horacio...@gmail.com>:
> Então peço ajuda dos senhores para pontuar o que eu devo analisar para que
> de forma númerica eu possa justificar que determinado serviço possa ser
> virtualizado e prever a capacidade, ou a necessidade de recursos que no
> ambiente virtual esse serviço irá requisitar.
> Então peço ajuda dos senhores para pontuar o que eu devo analisar para que
> de forma númerica eu possa justificar que determinado serviço possa ser
> virtualizado e prever a capacidade, ou a necessidade de recursos que no
> ambiente virtual esse serviço irá requisitar.
Recursos = Processamento, Memória, I/O.
Todo o software depende destes items e todos são mensuráveis. Essa
'analise' que você precisa é o mesmo raciocínio de dividir uma pizza
entre X pessoas, ou uma conta de bar entre Y pessoas, sendo que os 10%
do garçom é a margem de folga. :)
É clara que a limitação da arquitetura X86 é a quantidade de I/O. E
este é o principal fator a ser considerado na virtualização. Não
importa se os Guests são servidores email ou banco de dados, mas a
soma da utilização de I/O não deve ser maior que a quantidade
suportada pelo hardware. Isto também é o obvio para processamento e
memória. Se você seguir isto, conseguirá isolamento (termo utilizado
para refletir que os guests não interfiram entre si)
O 'iostat' é a ferramenta mais comumente utilizada para determinar a
utilização de I/O. Vale ressaltar que é melhor você não tentar prever
se se esta utilização vai subir ou cair, mas simplesmente aplicar
aritimética básica: I/O Guest A + I/O Guest B + I/O Guest X + Margem;
em conjunto com monitoração (automática ou manual) para migrar
máquinas quando a margem tender (durante um período) a um valor baixo.
--
Reinaldo de Carvalho
http://korreio.sf.net
http://python-cyrus.sf.net
"Don't try to adapt the software to the way you work, but rather
yourself to the way the software works" (myself)
horacio ibrahim
Dec 10, 2009, 1:55:24 PM12/10/09
to xen...@googlegroups.com
Blz Reinaldo ... reforçou o que eu imaginava e deu idéias para que eu possa iniciar o trabalho.
--
[]'s
Horacio Ibrahim S. Moreira
"...um burocrata, ele tem um manual, e o manual só diz o que pode e o que não pode. Se você apresentar uma coisa nova é proibido."
(Luís Inácio Lula da Silva 10º FISL/2009)
2009/12/10 Reinaldo de Carvalho <rein...@gmail.com>
--
[]'s
Horacio Ibrahim S. Moreira
"...um burocrata, ele tem um manual, e o manual só diz o que pode e o que não pode. Se você apresentar uma coisa nova é proibido."
(Luís Inácio Lula da Silva 10º FISL/2009)
Tobias Felipe
Dec 15, 2009, 12:32:18 PM12/15/09
to xen-br
Boa-tarde pessoal, novato postando aqui na lista (apesar de que eu já
lia faz um tempo).
Eu trabalho junto com o Horácio, e rascunhei aqui a documentação para
análise de virtualização.
Gostaria que o grupo desse uma olhada, se não for pedir muito, talvez
até ajude alguém. Críticas são bem vindas (É meio longo, e está num
corporativês que é necessário por aqui, foi mal :)
Estamos trabalhando num script pra automatizar o processo tb
-----------------------------------------------Inicio do documento
**Carga de CPU**
Interpreta-se como a taxa de utilização de uma CPU ao longo do tempo.
Números abaixo de 1 indicam uma subutilização, enquanto números acima
de 1 indicam sobreutilização.
Pode ser dado por:
#cat /proc/loadavg | cut -d” “ -f1
O comado dá a carga de cpu no último minuto, ajustar o final para f2
ou f3 para os últimos 5 ou 15 minutos, dependendo da frequência de
amostra.
A carga de CPU em razão do número de processadores não pode ser maior
que [1 – carga do virtualizador sem nenhum guest]. Atenção: Toda a
informação dada sobre multiprocessamento aplica-se a processadores de
vários núcleos (multicore).
Qualquer máquina com carga de cpu abaixo de 1 é uma candidata a
virtualização, enquanto cargas acima podem ser virtualizadas com o
número de cpus dedicados a ela devidamente corrigidos ou sem uma
definição de cpus dedicadas.
Por exemplo uma máquina com utilização de CPU de 1.89 deveria ser
colocada em um host utilizando um processador pelo menos 1.89x mais
rápido ou com 2 cpus alocados para ela (1.89 arredondado para cima).
Nunca colocar vários guests na mesma máquina onde a soma de carga de
cpu é maior que o número de processadores disponíveis em qualquer
configuração, as quedas bruscas de desempenho comparado com máquinas
físicas são praticamente garantidas.
**Uso Memória**
Uso de memória. Diferença entre memória total e livre. Dado por:
#free -mo | head -2 | tail -1 | tr -s " " | cut -d" " -f3
Memória livre, dada por:
#free -mo | head -2 | tail -1 | tr -s " " | cut -d" " -f4
A memória total utilizável é a soma das duas anteriores.
A máquina host deve ter pelo menos a memória total consumida pelas
máquinas guest mais o total de memória consumida sem nenhuma máquina
guest.
**Espera de I/O**
Porcentagem de tempo do processador esperando leitura/escrita
completar
#cat /proc/stat | head -1 | cut -d" " -f6
O retorno desse comando é o total de centésimos de segundo (ou outra
divisão, depende da opção USER_HZ na compilação do kernel) gastos com
espera de I/O desde o último boot. O script calcula as porcentagens
automaticamente.
A soma de espera de I/O de todas as máquinas a serem virtualizadas
não pode ser maior que o tempo ocioso do sistema (“idle”) da máquina
host.
Qualquer máquina que tiver um tempo de espera de I/O superior à
outras métricas do sistema (user, nice, system, idle) não é uma boa
candidata à virtualização.
**Leitura/Escrita em disco**
Os totais de leitura e escrita em disco(s) podem ser consultados no
pseudo-arquivo /proc/diskstats. O formato está descrito na
documentação do kernel, em “iostats.txt”, e é muito longo para ser
descrito aqui. O importante é que o os totais de leituras,
milisegundos gastos em leituras, escritas e milisegundos gastos em
escritas são lidos para cada disco e então somados para cada máquina
pelo script.
Os totais DE CADA VARIAVEL são armazenados internamente no kernel por
variáveis de 32 bits (unsigned int), e podem ser sobrescritos em um
sistema muito ocupado, ou com uptime muito alto. Para isso basta que
seu valor supere 4,294,967,295 (i.e. 2 ^ 32 -1) para qualquer uma
delas para cada disco. Deve-se levar em conta este dado nas
estatísticas.
Não há requerimento para as taxas de leitura e escrita, deve-se
entretanto observar que máquinas que se desviam muito das médias para
cima (banco de dados por exemplo) não recomenda-se serem
virtualizadas.
As máquinas adequadas para virtualização (quanto a esse parametro,
deve-se considerar as outras) são as que estiverem INFERIORES À MÉDIA
de leitura e escrita dos sistemas.
-------------------------------------------------------------Fim do
documento
On Dec 10, 4:55 pm, horacio ibrahim <horacioibra...@gmail.com> wrote:
> Blz Reinaldo ... reforçou o que eu imaginava e deu idéias para que eu possa
> iniciar o trabalho.
>
> 2009/12/10 Reinaldo de Carvalho <reinal...@gmail.com>
>
>
>
>
>
> > 2009/12/10 horacio ibrahim <horacioibra...@gmail.com>:
lia faz um tempo).
Eu trabalho junto com o Horácio, e rascunhei aqui a documentação para
análise de virtualização.
Gostaria que o grupo desse uma olhada, se não for pedir muito, talvez
até ajude alguém. Críticas são bem vindas (É meio longo, e está num
corporativês que é necessário por aqui, foi mal :)
Estamos trabalhando num script pra automatizar o processo tb
-----------------------------------------------Inicio do documento
**Carga de CPU**
Interpreta-se como a taxa de utilização de uma CPU ao longo do tempo.
Números abaixo de 1 indicam uma subutilização, enquanto números acima
de 1 indicam sobreutilização.
Pode ser dado por:
#cat /proc/loadavg | cut -d” “ -f1
O comado dá a carga de cpu no último minuto, ajustar o final para f2
ou f3 para os últimos 5 ou 15 minutos, dependendo da frequência de
amostra.
A carga de CPU em razão do número de processadores não pode ser maior
que [1 – carga do virtualizador sem nenhum guest]. Atenção: Toda a
informação dada sobre multiprocessamento aplica-se a processadores de
vários núcleos (multicore).
Qualquer máquina com carga de cpu abaixo de 1 é uma candidata a
virtualização, enquanto cargas acima podem ser virtualizadas com o
número de cpus dedicados a ela devidamente corrigidos ou sem uma
definição de cpus dedicadas.
Por exemplo uma máquina com utilização de CPU de 1.89 deveria ser
colocada em um host utilizando um processador pelo menos 1.89x mais
rápido ou com 2 cpus alocados para ela (1.89 arredondado para cima).
Nunca colocar vários guests na mesma máquina onde a soma de carga de
cpu é maior que o número de processadores disponíveis em qualquer
configuração, as quedas bruscas de desempenho comparado com máquinas
físicas são praticamente garantidas.
**Uso Memória**
Uso de memória. Diferença entre memória total e livre. Dado por:
#free -mo | head -2 | tail -1 | tr -s " " | cut -d" " -f3
Memória livre, dada por:
#free -mo | head -2 | tail -1 | tr -s " " | cut -d" " -f4
A memória total utilizável é a soma das duas anteriores.
A máquina host deve ter pelo menos a memória total consumida pelas
máquinas guest mais o total de memória consumida sem nenhuma máquina
guest.
**Espera de I/O**
Porcentagem de tempo do processador esperando leitura/escrita
completar
#cat /proc/stat | head -1 | cut -d" " -f6
O retorno desse comando é o total de centésimos de segundo (ou outra
divisão, depende da opção USER_HZ na compilação do kernel) gastos com
espera de I/O desde o último boot. O script calcula as porcentagens
automaticamente.
A soma de espera de I/O de todas as máquinas a serem virtualizadas
não pode ser maior que o tempo ocioso do sistema (“idle”) da máquina
host.
Qualquer máquina que tiver um tempo de espera de I/O superior à
outras métricas do sistema (user, nice, system, idle) não é uma boa
candidata à virtualização.
**Leitura/Escrita em disco**
Os totais de leitura e escrita em disco(s) podem ser consultados no
pseudo-arquivo /proc/diskstats. O formato está descrito na
documentação do kernel, em “iostats.txt”, e é muito longo para ser
descrito aqui. O importante é que o os totais de leituras,
milisegundos gastos em leituras, escritas e milisegundos gastos em
escritas são lidos para cada disco e então somados para cada máquina
pelo script.
Os totais DE CADA VARIAVEL são armazenados internamente no kernel por
variáveis de 32 bits (unsigned int), e podem ser sobrescritos em um
sistema muito ocupado, ou com uptime muito alto. Para isso basta que
seu valor supere 4,294,967,295 (i.e. 2 ^ 32 -1) para qualquer uma
delas para cada disco. Deve-se levar em conta este dado nas
estatísticas.
Não há requerimento para as taxas de leitura e escrita, deve-se
entretanto observar que máquinas que se desviam muito das médias para
cima (banco de dados por exemplo) não recomenda-se serem
virtualizadas.
As máquinas adequadas para virtualização (quanto a esse parametro,
deve-se considerar as outras) são as que estiverem INFERIORES À MÉDIA
de leitura e escrita dos sistemas.
-------------------------------------------------------------Fim do
documento
On Dec 10, 4:55 pm, horacio ibrahim <horacioibra...@gmail.com> wrote:
> Blz Reinaldo ... reforçou o que eu imaginava e deu idéias para que eu possa
> iniciar o trabalho.
>
>
>
>
>
>
> > 2009/12/10 horacio ibrahim <horacioibra...@gmail.com>:
Reinaldo de Carvalho
Dec 15, 2009, 1:00:37 PM12/15/09
to xen...@googlegroups.com
2009/12/15 Tobias Felipe <tobias...@gmail.com>:
abstrato, baseado em vários fatores.
Prefiro usar a média de uso de processamento com o desvio padrão para
demonstrar o uso do processador.
Use o vmstat.
Você esta pegando o valor de memória que inclui a cache de arquivos do FS.
A memória em uso é justamento a linha que a opção '-o' do comando free omite.
> **Uso Memória**
> Uso de memória. Diferença entre memória total e livre. Dado por:
> #free -mo | head -2 | tail -1 | tr -s " " | cut -d" " -f3
> Memória livre, dada por:
> #free -mo | head -2 | tail -1 | tr -s " " | cut -d" " -f4
> A memória total utilizável é a soma das duas anteriores.
> A máquina host deve ter pelo menos a memória total consumida pelas
> máquinas guest mais o total de memória consumida sem nenhuma máquina
> guest.
>
>
A leitura de I/O não é simples assim, use o iostat ao menos com duas interações.
O mesmo vale para processamento, depende de pelo menos duas interações
(top, vmstat, etc..)
> **Espera de I/O**
> Porcentagem de tempo do processador esperando leitura/escrita
> completar
> #cat /proc/stat | head -1 | cut -d" " -f6
> O retorno desse comando é o total de centésimos de segundo (ou outra
> divisão, depende da opção USER_HZ na compilação do kernel) gastos com
> espera de I/O desde o último boot. O script calcula as porcentagens
> automaticamente.
> A soma de espera de I/O de todas as máquinas a serem virtualizadas
> não pode ser maior que o tempo ocioso do sistema (“idle”) da máquina
> host.
> Qualquer máquina que tiver um tempo de espera de I/O superior à
> outras métricas do sistema (user, nice, system, idle) não é uma boa
> candidata à virtualização.
>
use o vmstat.
>
> **Leitura/Escrita em disco**
> Os totais de leitura e escrita em disco(s) podem ser consultados no
> pseudo-arquivo /proc/diskstats. O formato está descrito na
> documentação do kernel, em “iostats.txt”, e é muito longo para ser
> descrito aqui. O importante é que o os totais de leituras,
> milisegundos gastos em leituras, escritas e milisegundos gastos em
> escritas são lidos para cada disco e então somados para cada máquina
> pelo script.
> Os totais DE CADA VARIAVEL são armazenados internamente no kernel por
> variáveis de 32 bits (unsigned int), e podem ser sobrescritos em um
> sistema muito ocupado, ou com uptime muito alto. Para isso basta que
> seu valor supere 4,294,967,295 (i.e. 2 ^ 32 -1) para qualquer uma
> delas para cada disco. Deve-se levar em conta este dado nas
> estatísticas.
> Não há requerimento para as taxas de leitura e escrita, deve-se
> entretanto observar que máquinas que se desviam muito das médias para
> cima (banco de dados por exemplo) não recomenda-se serem
> virtualizadas.
> As máquinas adequadas para virtualização (quanto a esse parametro,
> deve-se considerar as outras) são as que estiverem INFERIORES À MÉDIA
> de leitura e escrita dos sistemas.
> -------------------------------------------------------------Fim do
> documento
>
Tudo que você precisa é vmstat + iostat com pelo menos duas interações.
Virtualizar baseia-se no fato de processamento, memória e I/O não
estejam saturados na máquina de origem. (sendo que normalmente
satura-se o I/O).
O detalhe é que é dificil afirmar que essa saturação será mantida em
uma máquina nova, pois em geral o hardware será melhor na máquina
Host, mesmo para um Guest desta.
> até ajude alguém. Críticas são bem vindas (É meio longo, e está num
> corporativês que é necessário por aqui, foi mal :)
> Estamos trabalhando num script pra automatizar o processo tb
>
Você já verificou como esse número da carga é gerado? Ele é algo muito
> corporativês que é necessário por aqui, foi mal :)
> Estamos trabalhando num script pra automatizar o processo tb
>
abstrato, baseado em vários fatores.
Prefiro usar a média de uso de processamento com o desvio padrão para
demonstrar o uso do processador.
Use o vmstat.
A memória em uso é justamento a linha que a opção '-o' do comando free omite.
> **Uso Memória**
> Uso de memória. Diferença entre memória total e livre. Dado por:
> #free -mo | head -2 | tail -1 | tr -s " " | cut -d" " -f3
> Memória livre, dada por:
> #free -mo | head -2 | tail -1 | tr -s " " | cut -d" " -f4
> A memória total utilizável é a soma das duas anteriores.
> A máquina host deve ter pelo menos a memória total consumida pelas
> máquinas guest mais o total de memória consumida sem nenhuma máquina
> guest.
>
>
O mesmo vale para processamento, depende de pelo menos duas interações
(top, vmstat, etc..)
> **Espera de I/O**
> Porcentagem de tempo do processador esperando leitura/escrita
> completar
> #cat /proc/stat | head -1 | cut -d" " -f6
> O retorno desse comando é o total de centésimos de segundo (ou outra
> divisão, depende da opção USER_HZ na compilação do kernel) gastos com
> espera de I/O desde o último boot. O script calcula as porcentagens
> automaticamente.
> A soma de espera de I/O de todas as máquinas a serem virtualizadas
> não pode ser maior que o tempo ocioso do sistema (“idle”) da máquina
> host.
> Qualquer máquina que tiver um tempo de espera de I/O superior à
> outras métricas do sistema (user, nice, system, idle) não é uma boa
> candidata à virtualização.
>
>
> **Leitura/Escrita em disco**
> Os totais de leitura e escrita em disco(s) podem ser consultados no
> pseudo-arquivo /proc/diskstats. O formato está descrito na
> documentação do kernel, em “iostats.txt”, e é muito longo para ser
> descrito aqui. O importante é que o os totais de leituras,
> milisegundos gastos em leituras, escritas e milisegundos gastos em
> escritas são lidos para cada disco e então somados para cada máquina
> pelo script.
> Os totais DE CADA VARIAVEL são armazenados internamente no kernel por
> variáveis de 32 bits (unsigned int), e podem ser sobrescritos em um
> sistema muito ocupado, ou com uptime muito alto. Para isso basta que
> seu valor supere 4,294,967,295 (i.e. 2 ^ 32 -1) para qualquer uma
> delas para cada disco. Deve-se levar em conta este dado nas
> estatísticas.
> Não há requerimento para as taxas de leitura e escrita, deve-se
> entretanto observar que máquinas que se desviam muito das médias para
> cima (banco de dados por exemplo) não recomenda-se serem
> virtualizadas.
> As máquinas adequadas para virtualização (quanto a esse parametro,
> deve-se considerar as outras) são as que estiverem INFERIORES À MÉDIA
> de leitura e escrita dos sistemas.
> -------------------------------------------------------------Fim do
> documento
>
Virtualizar baseia-se no fato de processamento, memória e I/O não
estejam saturados na máquina de origem. (sendo que normalmente
satura-se o I/O).
O detalhe é que é dificil afirmar que essa saturação será mantida em
uma máquina nova, pois em geral o hardware será melhor na máquina
Host, mesmo para um Guest desta.
horacio ibrahim
Dec 15, 2009, 11:42:42 PM12/15/09
to xen...@googlegroups.com
Fala Tobias!
Blz! Cara...vou dá olhada no doc. Bem-vindo as postagens...
As dicas do Reinaldo são pontuais, principalmente na carga de CPU. É realmente muito abstrato e ainda não vi quem use para mensurar, por exemplo, testes de carga.
Mas o caminho é esse mesmo...!
Blz! Cara...vou dá olhada no doc. Bem-vindo as postagens...
As dicas do Reinaldo são pontuais, principalmente na carga de CPU. É realmente muito abstrato e ainda não vi quem use para mensurar, por exemplo, testes de carga.
Mas o caminho é esse mesmo...!
2009/12/15 Reinaldo de Carvalho <rein...@gmail.com>
--
Você recebeu esta mensagem porque está inscrito em Grupo "xen-br" do Grupos Google.
Para enviar mensagens para este grupo, envie um email para xen...@googlegroups.com
Para anular a inscrição neste grupo, envie um email para xen-br-un...@googlegroups.com
Para mais opções, visite este grupo em http://groups.google.com/group/xen-br?hl=pt-BR
Site do GU Xen-BR: http://www.xen-br.org
Antes de enviar sua primeira mensagem leia atentamente as regras para participação no site http://groups.google.com/group/xen-br/web/regras?hl=pt-BR
Tobias Felipe
Dec 16, 2009, 10:50:10 AM12/16/09
to xen-br
Oi Reinaldo,
Todos os valores na verdade vão ser considerados pelas suas médias e
desvios, não é leitura única.
Eu tive que pegar os valores nas fontes pq o debian não inclui o
iostat por padrão, e instalar em todas
as nossas máquinas é inviável.
> Você já verificou como esse número da carga é gerado? Ele é algo muito
> abstrato, baseado em vários fatores.
>
> Prefiro usar a média de uso de processamento com o desvio padrão para
> demonstrar o uso do processador
Qual dado você costuma colher para o uso do processamento?
On Dec 15, 4:00 pm, Reinaldo de Carvalho <reinal...@gmail.com> wrote:
> 2009/12/15 Tobias Felipe <tobias.fis...@gmail.com>:
> Reinaldo de Carvalhohttp://korreio.sf.nethttp://python-cyrus.sf.net
Todos os valores na verdade vão ser considerados pelas suas médias e
desvios, não é leitura única.
Eu tive que pegar os valores nas fontes pq o debian não inclui o
iostat por padrão, e instalar em todas
as nossas máquinas é inviável.
> Você já verificou como esse número da carga é gerado? Ele é algo muito
> abstrato, baseado em vários fatores.
>
> Prefiro usar a média de uso de processamento com o desvio padrão para
> demonstrar o uso do processador
On Dec 15, 4:00 pm, Reinaldo de Carvalho <reinal...@gmail.com> wrote:
> 2009/12/15 Tobias Felipe <tobias.fis...@gmail.com>:
Reinaldo de Carvalho
Dec 16, 2009, 11:40:27 AM12/16/09
to xen...@googlegroups.com
2009/12/16 Tobias Felipe <tobias...@gmail.com>:
> Oi Reinaldo,
coleta e comparações (no caso do IO e processamento). Para I/O sugiro
que você use o iostat.
>> Prefiro usar a média de uso de processamento com o desvio padrão para
>> demonstrar o uso do processador
> Qual dado você costuma colher para o uso do processamento?
>
O uso do processador, o valor que e mostrado no top ou vmstat.
Estes fazem a amostragem e comparação automática, exibindo valores
mensuráveis. Tanto o top, vmstat e iostat não possuem dados válidos na
primeira interação (que é o valor que voce obteria nos fontes).
Exemplo:
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
2 0 0 1134124 15308 167612 0 0 206 27 128 1850 11 3 80 6
0 0 0 1134116 15308 167620 0 0 0 0 120 757 12 0 88 0
0 0 0 1134116 15308 167620 0 0 0 0 124 789 0 11 89 0
A primeira interação deve ser desconsiderada. Ou seja, ler dos
'fontes' apenas um vez mostrar dados incorretos.
> Oi Reinaldo,
>
> Eu tive que pegar os valores nas fontes pq o debian não inclui o
> iostat por padrão, e instalar em todas
> as nossas máquinas é inviável.
>
Os valores 'das fontes' são mais complexo, e depende uma segunda
> Eu tive que pegar os valores nas fontes pq o debian não inclui o
> iostat por padrão, e instalar em todas
> as nossas máquinas é inviável.
>
coleta e comparações (no caso do IO e processamento). Para I/O sugiro
que você use o iostat.
>> Prefiro usar a média de uso de processamento com o desvio padrão para
>> demonstrar o uso do processador
> Qual dado você costuma colher para o uso do processamento?
>
Estes fazem a amostragem e comparação automática, exibindo valores
mensuráveis. Tanto o top, vmstat e iostat não possuem dados válidos na
primeira interação (que é o valor que voce obteria nos fontes).
Exemplo:
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
2 0 0 1134124 15308 167612 0 0 206 27 128 1850 11 3 80 6
0 0 0 1134116 15308 167620 0 0 0 0 120 757 12 0 88 0
0 0 0 1134116 15308 167620 0 0 0 0 124 789 0 11 89 0
A primeira interação deve ser desconsiderada. Ou seja, ler dos
'fontes' apenas um vez mostrar dados incorretos.
Reinaldo de Carvalho
Dec 16, 2009, 1:02:27 PM12/16/09
to xen...@googlegroups.com
Refletindo sobre a frase "Estatistica/Variáveis que justifique portar
um serviço" cheguei a conclusão que todos os serviços são viáveis de
serem virtualizados.
A exceção são máquinas com carga excedida, mas isso é um comportamento
não-comum e até não aceitável, pois se a máquina estiver nesta
situação o serviço 'on the metal' já estará com desempenho
comprometido e/ou insatisfatório; e considerando um ambiente com
gestão de recursos, os serviços não deveriam chegar ao nível de
saturamento (carga próxima ou superior a do hardware), sendo assim, em
um ambiente controlado, do ponto de vista de carga tudo já seria
passível de virtualização.
Se existem máquinas 'on the metal' saturadas, o problema é outro e não
"Virtualizar ou não". Pois essa situação já não deveria estar
acontecendo (a saturação). Ou seja, o problema é a inexistência de
gestão de recursos que permitiu a saturação das máquinas ao invés de
já ter ocorrido a troca/adição de hardware ou ajuste no software.
um serviço" cheguei a conclusão que todos os serviços são viáveis de
serem virtualizados.
A exceção são máquinas com carga excedida, mas isso é um comportamento
não-comum e até não aceitável, pois se a máquina estiver nesta
situação o serviço 'on the metal' já estará com desempenho
comprometido e/ou insatisfatório; e considerando um ambiente com
gestão de recursos, os serviços não deveriam chegar ao nível de
saturamento (carga próxima ou superior a do hardware), sendo assim, em
um ambiente controlado, do ponto de vista de carga tudo já seria
passível de virtualização.
Se existem máquinas 'on the metal' saturadas, o problema é outro e não
"Virtualizar ou não". Pois essa situação já não deveria estar
acontecendo (a saturação). Ou seja, o problema é a inexistência de
gestão de recursos que permitiu a saturação das máquinas ao invés de
já ter ocorrido a troca/adição de hardware ou ajuste no software.
horacio ibrahim
Dec 16, 2009, 6:34:17 PM12/16/09
to xen...@googlegroups.com
Reinaldo, sendo sincero pensei assim também, mas digamos que eu queira alocar um hardware e que eu possa virtualizar apenas 1 máquinas física "não tem finalidade*" para mim virtualizar.
Então contextualizando se duas maquinas físicas, não saturadas, utilizando 40% (a grosso modo) de processamento numa matemática básica só poderei virtualizar 2 máquinas dessas. Certo?
Por isso que é importante mensurar, pois quando começamos a pensar na continuidade e no impacto que o ambiente virtualizado não pode surge a preocupação.
Agora vem o breakdown. Se eu mensurar a carga de processamento de forma genérica poderá impactar em algum uso de processamento específico.
* Ainda que não parece ainda tem finalidade, mas não voi entrar no assunto.
Então contextualizando se duas maquinas físicas, não saturadas, utilizando 40% (a grosso modo) de processamento numa matemática básica só poderei virtualizar 2 máquinas dessas. Certo?
Por isso que é importante mensurar, pois quando começamos a pensar na continuidade e no impacto que o ambiente virtualizado não pode surge a preocupação.
Agora vem o breakdown. Se eu mensurar a carga de processamento de forma genérica poderá impactar em algum uso de processamento específico.
* Ainda que não parece ainda tem finalidade, mas não voi entrar no assunto.
2009/12/16 Reinaldo de Carvalho <rein...@gmail.com>
--
Você recebeu esta mensagem porque está inscrito em Grupo "xen-br" do Grupos Google.
Para enviar mensagens para este grupo, envie um email para xen...@googlegroups.com
Para anular a inscrição neste grupo, envie um email para xen-br-un...@googlegroups.com
Para mais opções, visite este grupo em http://groups.google.com/group/xen-br?hl=pt-BR
Site do GU Xen-BR: http://www.xen-br.org
Antes de enviar sua primeira mensagem leia atentamente as regras para participação no site http://groups.google.com/group/xen-br/web/regras?hl=pt-BR
Reinaldo de Carvalho
Dec 16, 2009, 7:14:20 PM12/16/09
to xen...@googlegroups.com
2009/12/16 horacio ibrahim <horacio...@gmail.com>:
> Reinaldo, sendo sincero pensei assim também, mas digamos que eu queira
> alocar um hardware e que eu possa virtualizar apenas 1 máquinas física "não
> tem finalidade*" para mim virtualizar.
>
> Então contextualizando se duas maquinas físicas, não saturadas, utilizando
> 40% (a grosso modo) de processamento numa matemática básica só poderei
> virtualizar 2 máquinas dessas. Certo?
>
> Reinaldo, sendo sincero pensei assim também, mas digamos que eu queira
> alocar um hardware e que eu possa virtualizar apenas 1 máquinas física "não
> tem finalidade*" para mim virtualizar.
>
> Então contextualizando se duas maquinas físicas, não saturadas, utilizando
> 40% (a grosso modo) de processamento numa matemática básica só poderei
> virtualizar 2 máquinas dessas. Certo?
>
Essa é a idéia.
> Por isso que é importante mensurar, pois quando começamos a pensar na
> continuidade e no impacto que o ambiente virtualizado não pode surge a
> preocupação.
>
Mas quando se tem 'live migration' não é necessário tanta conta. ;)
Você precisa ter máquinas, mesmo que desligadas para serem ativadas
quando necessário. Não que você va ficar usando isso todo dia, mas
quando notar saturação constante (horas, dias, etc) então migre.
> Agora vem o breakdown. Se eu mensurar a carga de processamento de forma
> genérica poderá impactar em algum uso de processamento específico.
>
Pode ocorrer. Mas pode entrar no caso acima, do 'live migration'. Veja
que a "pós-mensuração" ou "monitamento de carga*" pode detectar isso.
* I/O e processamento principalmente.
horacio ibrahim
Dec 16, 2009, 7:18:45 PM12/16/09
to xen...@googlegroups.com
Pow...o bom e velho live migration. Realmente pelos recursos disponíveis que tenho em mãos dá para relaxar um pouco visto os benefícios do live.
2009/12/16 Reinaldo de Carvalho <rein...@gmail.com>
2009/12/16 horacio ibrahim <horacio...@gmail.com>:
--
Você recebeu esta mensagem porque está inscrito em Grupo "xen-br" do Grupos Google.
Para enviar mensagens para este grupo, envie um email para xen...@googlegroups.com
Para anular a inscrição neste grupo, envie um email para xen-br-un...@googlegroups.com
Para mais opções, visite este grupo em http://groups.google.com/group/xen-br?hl=pt-BR
Site do GU Xen-BR: http://www.xen-br.org
Antes de enviar sua primeira mensagem leia atentamente as regras para participação no site http://groups.google.com/group/xen-br/web/regras?hl=pt-BR
Reply all
Reply to author
Forward
0 new messages