Análise de Performance em Linux e Windows - II

Acho que encontrei um modo bastante fácil para resolver um problema que já me vinha a atormentar há algum tempo.

Eu explico, como fazer para recolher, a certas horas do dia, alguns dados dos computadores que interessam, uns Linux e outros Windows e fazer uns gráficos todos bonitos para que depois o administrador de sistemas olhasse para eles (os gráficos) ?

Ora a solução por mim adoptada envolve uns scripts, criados para a funçao, e um programa muito versátil e simples de usar chamado Gnuplot.

Para recolher os dados em Linux uso um shell-script que me vai ler as informações que quero ao /proc e coloca num ficheiro do tipo .csv; Para efectuar a recolha em Windows uso um script VBS, executado através do "motor" WSH e que também exporta esses dados pera um ficheiro tipo .csv.

Por fim tenho um terceiro script, para o gnuplot, que me vai criar os gráficos relevantes e exporta-os para um ficheiro de imagem (no caso PNG).

A vantagem de executar todas estas acções através de scripts é a facilidade de parametrização e definição de horários para a recolha e geração dos ditos gráficos.

Assim, basta um cron job no Linux ou uma tarefa agendada no Windows para criar automaticamente o que é pretendido.

Um resultado possível é este :


Mostra um gráfico com três indicadores relativos à utilização de memória numa máquina Linux.

Geek test ...

Este teste deve interessar aos meus "colegas blogueiros" do PlanetGeek :)

Nerd Score ...

Cá vai mais um teste.. :)




até breve !

Análise de Performance em Linux e Windows - I

Tenho estado a experimentar a melhor maneira de analisar a performance de sistemas Windows e Linux em Windows e Windows e Linux em Linux... Parece uma lenga-lenga mas interessa por vezes ter dados de performance de um conjunto de servidores, em ambientes heterogéneos (ou seja, dados de máquinas Linux e máquinas Windows) e analizá-los numa outra máquina (normalmente um computador pessoal ou portátil)...

Para recolher as informações relevantes podemos recorrer a diversos métodos mas, para o caso, sigo "a lei do menor esforço" e uso as ferramentas disponíveis com os diversos S.O., no caso do Windows uso o Performance Monitor e no caso do Linux uso informações do /proc. Esta acção permite-me obter os dados que quero todos "arrumadinhos" num ficheiro de texto que é facilmente "importável" para a aplicação de análise.

Ora aqui é que a porca torce o rabo... porquê ? Porque não me apetece usar o MS Excel para analisar os dados e fazer os respectivos gráficos, e nem sequer me apetece muito usar o OpenOffice.org Calc... Não é que estes dois programas não sejam capazes, nada disso, mas gosto das coisas mais automáticas. Gostava de fazer assim:

1. Correr o script de recolha / tarefa do PerfMonitor
2. Criar os gráficos relevantes.
3. Ver os ditos num PDF todo geitoso.
   

Só assim, sem mais nada...
E gostava que isto fosse possível nos dois S.O., sem grandes complicações, artimanhas ou "instala-mais-este-software-que-te-faz-isso-e-te-tira-cafés-mas-
-que-só-dá-para-ver-assim-ou-assado".
E gostava que houvesse maneira de fazer isto tudo a partir de um scriptezito às segundas de manhã ou quartas à tarde ou quando quisesse sem pensar mais nisso.
E gostava de receber os ditos gráficos por mail...

Para já concluí a fase 1. Tanto no Windows como no Linux. Agora vou passar à fase 2, penso que daqui a um ou dois dias já tenho o que quero !


Ah!, é verdade, e também gostava de ganhar o EuroMilhões.... :)

De volta

Cá estou de volta, depois de uns (merecidos) dias de férias....

Estes dias serviram também para pensar um bocadito sobre alguns assuntos que vou deixando pendentes e arrumar mentalmente a casa.

Brevemente terei aqui mais artigos de geito :)

Férias

Também tenho direito :)

Os próximos 5 dias estarei ausente e (quase) incomunicável !!

Até breve

SAN - NAS

Ao dimensionar um Sistema de Informação existem vários pontos a ter em conta, um dos quais é o espaço necessário para armazenar a informação pretendida.

Ora, visto que um Sistema de Informação não é uma entidade estática mas irá sofrer evoluções, é necessário contar também com as necessidades futuras que possam vir a exigir mais espaço de armazenamento.

Nesta área há duas tecnologias principais que permitem maior flexibilidade do nosso armazém de dados: NAS e SAN, ou seja "Netwok Attached Storage" e "Storage Area Network". Embora os nomes sejam parecidos e o fim seja o mesmo, os conceitos que estão por detrás de cada uma delas são muito diferentes e assentam em pressupostos também diferentes. Uma SAN é constituída por um conjunto de discos (o armazenamento propriamente dito) que se liga a um computador através de uma rede dedicada, normalmente de fibra óptica. Um sistema NAS é um conjunto de discos que está ligado à rede local (LAN) através de Ethernet. Dito assim, até parece que não existe grande diferença entre os dois, a não ser a tecnologia de rede usada. A outra (maior) diferença entre as duas opções é o tipo de informação que fornecem aos sistemas a eles ligados.

Uma SAN fornece os dados que tem armazenados sob a forma de "blocos" tal como se fosse mais um disco interno de um servidor. Deste ponto de vista a SAN serve para "esticar" o espaço disponível para armazenar ficheiros num servidor.

Um sistema NAS fornece os dados sob a forma de ficheiros, ou seja, comporta-se como um servidor de ficheiros independente do resto dos servidores da rede.

Apresentado um exemplo:
Temos um computador na rede, que precisa de aceder ao ficheiro "Projecto1.odt" armazenado num sistema NAS. O caminho para esse ficheiros será do género [Usando caminhos SAMBA/CIFS]:

\\SistemaNAS\Partilha\Projecto1.odt

Se, pelo contrário, o mesmo ficheiro estiver numa SAN, gerida pelo servidor Server1:

\\Server1\Partilha\Projecto1.odt

Portanto, do ponto de vista dos clientes, nada a assinalar. Então porquê esta "questão" à volta da tecnologia a implementar ? Porque não escolher uma delas e seguir em frente ??
Essencialmente porque as Bases de Dados não gostam de NAS, i.e., se tivermos que alojar uma Base de Dados de alguma dimensão torna-se incomportável transferir um ficheiro "pela rede".

Vendo outro exemplo:

Supomos que existe uma Base de Dados de suporte ao nosso Sistema de Informação que irá ter cerca de 10 GiB.
Ao alojar este ficheiro no NAS, teremos que configurar o SGBD para o usar e, uma vez que os SGBD requerem acesso exclusivo a todo o ficheiro da BD, este teria que ser transferido na totalidade para o sistema que corre o SGBD sempre que houvesse necessidade de leitura/escrita na BD. Mesmo com FastEthernet de 1Gb/s, a transferência do ficheiro demoraria cerca de 2 minutos. Claro que este tempo de espera ao abrir o ficheiro será incomportável para as aplicações, já para não falar em recursos de memória que seria necessários do lado do SGBD.
Se o alojarmos numa SAN, podemos atribuir essa área da SAN ao servidor do SGBD e comportar-se-á como armazenamento local. Quer isto dizer que nunca haverá necessidade de transferir todo o ficheiro, pois em caso de acesso a ficheiros locais só os blocos envolvidos são transferidos.

Para além das razões "técnicas" de acesso a ficheiros, ecistem também diferenças significativas na instalação, configuração e administração dos dois tipos de armazenamento, o que leva a que muitas vezes o NAS seja preferido pelo seu menor custo e maior facilidade de implementação. Pelo contrário, quando o que está em causa é a velocidade de acesso e facilidade de expansão (e o dinheiro chega) prefere-se implementar uma SAN.

Ultimamente tem-se vindo a aproximar as duas filosofias pela junção de um NAS na interface da SAN com a rede, o que cria, na prática, um NAS muito escalável e bastante rápido.

Tanto num NAS como numa SAN, são aplicáveis outros conceitos relativos ao armazenamento, nomeadamente níveis de RAID e tecnologias de Discos, que fiarão ar uma próxima ocasião.

Sistemas de Informação - parte III

Tal como prometi no artigo sobre documentos dispersos e a sua relação com os sistemas de informação, este artigo aborda o terceiro componente que, na minha opinião, deve ser considerado parte dum sistema de informação bem estruturado e desenvolvido: o e-mail.

O e-mail é, dos serviços da Internet, um dos mais antigos e um dos mais usados. Embora criado há já muitos anos o protocolo POP sofreu várias revisões, sendo a última e mais recente a chamada versão 3, constituindo assim o protocolo POP3, descrito no RFC 1939, de Maio de 1996.

Uma vez que as condições das redes informáticas são agora muito diferentes de há dez anos atrás, nomeadamente na disponibilidade de acesso à informação por parte dos utilizadores, a quantidade de dados que é necessário manter na forma de mensagens de e-mail é cada vez maior. A existência de regulamentação legal para tornar obrigatória a manutenção de um arquivo de mensagens de e-mail, tal como os existentes para correio em papel, aumenta ainda mais essa necessidade.

O que fazer então para arquivar os milhares de mensagens que nos chegam por ano às caixas de correio, e, mais ainda, como fazer para que os utilizadores tenham acesso a tais quantidades de e-mail sem prejudicar o desempenho da rede ou do sistema onde estão a trabalhar ??

Deixo esta pergunta no ar, para reflectirem durante este mês de férias... Daqui a algum tempo voltaremos a este tema...

Eu sou...

Aqui encontra-se um teste para descobrir qual o que seriam se fossem uma linguagem de programação. Eu seria PHP... até concordo :)



Which Programming Language are You?

Podem ver todos os resultados possíveis, aqui.

Na mesma linha, aqui podemos encontrar a variante: se eu fosse um Sistema Operativo...

O meu resultado é:



Which OS are You?

Sistemas de Informação - parte II

Boas,

No seguimento do post anterior sobre o que constitui um Sistema de Informação, interessa saber como fazer a integração da informação presente em conteúdo não estruturado (nos tais ficheiros de aplicações diversas) com a informação presente de forma estruturada na Base de Dados que suporta o Sistema de Informação.

Um método cada vez mais comum é transformar os ficheiros em documentos XML que depois podem ser integrados nas Bases de Dados, pois os principais fabricantes de Bases de Dados já incluem esta funcionalidade há algum tempo. Uma vantagem deste método é que pode permitir a pesquisa de informação dentro do documento original usando a linguagem XPath o uoutra semelhante. A principal desvantagem é a necessidade de conversão de documentos, que podem ser milhares ou mais, tornando este processo num processo moroso e sujeito a erros.

Podemos também admitir que os documentos existem fora da Base de Dados e criar um repositório, eventualmente com controlo de versões ou mantido por uma ferramenta de trabalho colaborativo. Esta segunda hipótese resulta normalmente da necessidade de rever ou alterar documentos a posteriori.

Ambos os métodos têm as suas vantagens e o seus pontos fracos, que devem ser avaliados antes da implementação.

Para um próximo artigo, fica o grande problema do e-mail...