![Fechar [x]](http://dw1.s81c.com/i/c.gif){kind=small}
Dispositivos virtuais são soluções de software pré-construídas compostas de uma ou mais máquinas virtuais que são empacotadas, atualizadas, mantidas e gerenciadas como uma unidade. Ao contrário de um dispositivo de hardware tradicional, estes dispositivos de software permitem que os clientes adquiram, implementem e gerenciem facilmente pilhas de soluções pré-integradas. Isso acelera o tempo de retorno sobre o investimento e simplifica o desenvolvimento, distribuição e gerenciamento de software.
Dispositivos virtuais estão mudando o paradigma de distribuição de software, pois permitem que construtores de aplicativos otimizem a pilha de software para aplicativos e entreguem ao usuário final um serviço de software pronto para ser usado.
Enquanto dispositivos virtuais atuais contém apenas uma máquina virtual (VM), aplicativos corporativos modernos modelam arquiteturas orientadas a serviço (SOA) com várias camadas, nas quais cada camada contém uma ou mais máquinas. O modelo de VM única não é suficiente para este tipo de aplicativo. Distribuir serviços multicamada na forma de dispositivo de software requer dispositivo virtual composto de mais VMs que possam cooperar.
Por exemplo, imagine um aplicativo da Web típico composto de três camadas. Uma camada da Web que implementa a lógica de apresentação, uma camada do servidor de aplicativo que implementa a lógica de negócios, e uma camada de banco de dados de backend. Uma implementação simples dividiria isso em três máquinas virtuais, uma para cada camada. Dessa maneira, o aplicativo pode escalar de uma fração de um host físico para três hosts físicos.
Em um datacenter virtual, a implementação e a desativação de dispositivos complexos requer que várias etapas de configuração sejam executadas para que o dispositivo esteja pronto para uso.
- Reconfiguração necessária para designar parâmetros específicos do OS, como informações de rede: IP, nome de host, senhas etc.
- Reconfiguração para estabelecer/remover a comunicação entre:
- Componentes diferentes do mesmo produto sendo executados em máquinas virtuais diferentes.
- Produtos diferentes sendo executados em máquinas virtuais diferentes.
O primeiro problema descrito na lista é tratado com a tecnologia de mecanismo de ativação, software integrado no dispositivo virtual que é ativado durante o primeiro boot do dispositivo, após a implementação.O mecanismo de ativação e plug-ins de customização podem ser escritos e fornecidos para configurar o dispositivo virtual no sistema de destino.
O problema descrito no segundo item da lista não foi tratado. Hoje, reconfigurações são realizadas manualmente ou chamando scripts predefinidos com valores estáticos na entrada. Nós propomos suporte a plug-and-play de dispositivos virtuais complexos em um datacenter virtual para resolver essa questão. Dessa maneira, as máquinas virtuais poderão descobrir e conectar automaticamente umas às outras com base em conexões predefinidas, porém mais flexíveis; StereoCable é complementar com o Mecanismo de Ativação e pode coexistir com ele facilmente. Aliás, o AE pode ser explorado para configurar automaticamente o StereoCable no momento do boot.
Princípios de design do StereoCable
Antes de descrever a arquitetura e fluxo do sistema, vamos apresentar um conceito essencial neste o artigo, o de StereoCable.
StereoCable é um artefato que descreve como estabelecer cooperação baseada em funções entre duas entidades sendo executadas em máquinas virtuais diferentes, por exemplo:
(PRODA_UI,PRODA_SERVER) ... (PRODA_SERVER,PRODB_SERVER) ... (PRODA_UI,PRODB_SERVER)
Um artefato StereoCable é composto por duas partes (as quais chamaremos de funções):
- A função de soquete. O soquete descreve as informações que precisam ser fornecidas por uma entidade para estabelecer conexão com outra entidade. Com é designada uma função de soquete a uma VM em um ambiente particular, ela publica as informações exigidas pela definição de soquete.
- A função de plugue. O plugue descreve as ações que precisam
ser executadas por uma entidade em uma VM para estabelecer
cooperação com outra entidade sendo executada em uma máquina
virtual diferente. Quando é designada uma função de plugue a
uma VM em um ambiente particular, ela:
- Localiza uma VM com a função de soquete correspondente no mesmo ambiente
- Recupera as informações de soquete publicadas
- Executa a ação descrita na definição do plugue.
Para representar um artefato StereoCable, foi definido um esquema XML. A Listagem 1 é um exemplo de informações de StereoCable:
Listagem 1. Informações de StereoCable em XML
<StereoCable>
<StereoCableID>StereoCableID1</StereoCableID>
<Description>PRODA UI Automatic
Reconfiguration</Description>
<PlugSection> <Description>PRODA UI
Server</Description>
<PlugID>PRODA_UI</PlugID>
<ConfigurationActions>
<ConfigurationAction>
<Description>Description</Description>
<ID>ID</ID>
<Trigger>Deployment</Trigger>
<Action>
<ActionType>script</ActionType>
<ActionDetail>
<ConfigurationParameters>
<ConfigurationParamter>
<ConfigurationName>host</ConfigurationName>
</ConfigurationParamter>
<ConfigurationParamter>
<ConfigurationName>port</ConfigurationName>
</ConfigurationParamter>
<ConfigurationParamter>
<ConfigurationName>name</ConfigurationName>
</ConfigurationParamter>
<ConfigurationParamter>
<ConfigurationName>user</ConfigurationName>
</ConfigurationParamter>
</ConfigurationParameters>
<Operation>/pino/driver4/scripts/PRODAUI.sh</Operation>
</ActionDetail> </Action>
</ConfigurationAction>
</ConfigurationActions>
</PlugSection> <SocketSection>
<Description>PRODA
Master</Description>
<SocketID>PRODA_SERVER</SocketID>
<PublishedParameters>
<ConfigurationParameter>
<ConfigurationName>host</ConfigurationName>
<ConfigurationValue>nc125050.romelab.it.ibm.com</ConfigurationValue>
</ConfigurationParameter>
<ConfigurationParameter>
<ConfigurationName>port</ConfigurationName>
<ConfigurationValue>31117</ConfigurationValue>
</ConfigurationParameter>
<ConfigurationParameter>
<ConfigurationName>name</ConfigurationName>
<ConfigurationValue>PRODA-istributed</ConfigurationValue>
</ConfigurationParameter>
<ConfigurationParameter>
<ConfigurationName>user</ConfigurationName>
<ConfigurationValue>PRODA85mdm</ConfigurationValue>
</ConfigurationParameter>
</PublishedParameters>
</SocketSection> </StereoCable> |
A Figura 1 ilustra os componentes do sistema StereoCable.
Figura 1. Componentes do StereoCable
O sistema StereoCable é composto de:
- Mecanismo StereoCable: Uma entidade de software carregada na VM para processar funções designadas de processo de acordo com as informações de StereoCable expressas em formato XML. Esse mecanismo também é capaz de processar eventos de VM: por exemplo, a implementação e uma nova VM ou a remoção de uma VM existente, para tomar as medidas de configuração apropriadas.
- Registro de StereoCable: Um repositório que mantém registro dos soquetes disponíveis e os fornece aos plugues sob solicitação (baseado em restrições predefinidas). Esse é o elemento mais obrigatório, pois as VMs das implementações de virtualização de alguns fornecedores podem publicar e compartilhar esse tipo de informações diretamente.
- Interface com o usuário/Interface de linha de comando do StereoCable: A entidade de software usada para trabalhar com VMs e informações de plugue e soquete, e que exibe suas inter-relações. A UI pode acessar as informações que conectam com o Registro do StereoCable e diretamente com as VMs.
(A implementação do StereoCable que fornecemos neste artigo inclui suporte para VMware; especificamente VMware ESX 3.5 e vSphere 4. Os mecanismos de ativação conectam usando a API VMware VI SDK e o Registro do StereoCable é o VMware VirtualCenter. O sistema operacional guest suportado é SLES10.)
Em seguida, vamos discutir como StereoCable processa ações.
Vamos examinar os dois tipos de processos encontrados com StereoCable — o processo de inicialização do mecanismo e o processamento dinâmico do StereoCable (a vantagem de automação que um artefato StereoCable tem em relação ao processo tradicional de descoberta e reconfiguração de conexão de VM). Para esta seção, pensamos que seria mais claro e conciso oferecer uma série de etapas e um fluxograma para ilustrar o processo.
As etapas principais para inicialização e processamento dinâmico do StereoCable
O processo de Inicialização do Mecanismo segue estas etapas:
- O Mecanismo do StereoCable conecta-se ao registro para recuperar as funções e os StereoCables. Esta etapa pode incluir autodescoberta do Registro se o protocolo usado pelo Mecanismo permitir, por exemplo, SLP (service discovery protocol que permite que computadores e outros dispositivos localizem serviços em uma LAN sem configuração anterior).
- Recuperar as funções da VM e os ambientes aos quais a VM pertence.
- Recuperar os StereoCables associados à VM.
- Mecanismo do StereoCable processa os StereoCables contidos no arquivo StereoCables.xml.
- Desativar a funcionalidade StereoCable geral para aquela VM.
- Para todas as funções de soquete em StereoCables.xml, se a
função for igual a uma das funções da VM:
- Verificar se a dependência está OK. Se não estiver, colocar o soquete em uma fila em operação.
- Recuperar os atributos do soquete, como descritos no arquivo XML.
- Publicar os atributos do soquete.
- Publicar a informação de que o soquete está ativo agora.
- Enviar um evento para o soquete publicado.
- Colocar o soquete na tabela ativa de StereoCable; também especificar as informações às quais o soquete é conectado.
- Ativar a funcionalidade geral do StereoCable para aquela VM.
- Para todas as funções de plugue em StereoCables.xml; se a
função for igual a uma das funções da VM:
- Verificar se a dependência está OK. Se não estiver, colocar o plugue em uma fila em operação.
- Recuperar as informações relacionadas ao soquete (função...) descritas no arquivo XML.
- Descobrir as VMs que fornecem o soquete apropriado e que pertencem ao mesmo ambiente.
- Para todas as VMs descobertas:
- Decidir, baseado nas regras definidas no arquivo XML, qual VM será selecionada se mais de uma tiver sido descoberta.
- Recuperar os atributos do soquete publicado se o status do soquete estiver ativo.
- Chamar as ações de configuração; passar as informações recuperadas como um parâmetro.
- Publicar as informações; o plugue agora está ativo, e também descreve as informações sobre o soquete ao qual está conectado.
- Enviar um evento para o plugue publicado.
- Colocar o plugue na tabela ativa de StereoCable; especificando a informação sobre o soquete ao qual está conectado.
- Se não houver VM disponível, ou se a VM estiver disponível, mas o soquete não estiver ativo, colocar o StereoCable na fila em funcionamento para processamento, especificando as funções e ambiente de teste necessários.
As seguintes etapas (elas continuam a partir das anteriores) mostram como o processamento dinâmico do StereoCable funciona.
- Coletar periodicamente eventos StereoCable (soquete criado, soquete removido, soquete atualizado) e eventos relacionados a VM (implementação de VM, desativação de VM) para VMs com funções específicas.
- Para toas as funções de plugue na fila em funcionamento:
- Se uma nova VM tiver sido descoberta e ela publicar
um soquete ativo solicitado
- Recuperar os atributos do soquete publicado se o status do soquete estiver ativo.
- Chamar as ações e configuração, passando-os como um parâmetro, a partir das informações recebidas.
- Publicar a informação de que o plugue agora está ativo, descrevendo também a informação sobre o soquete ao qual está conectado.
- Remover o plugue da fila em funcionamento do StereoCable.
- Colocar o plugue na tabela ativa de StereoCable, especificando também a informação sobre o soquete ao qual está conectado.
- Enviar um evento para o plugue publicado.
- Se for removida do datacenter uma VM que publica um
soquete atualmente em uso por um plugue salvo na
tabela ativa de StereoCable:
- Chamar as ações de configuração de remoção, passando as informações relacionadas ao soquete como um parâmetro.
- Remover o plugue da tabela ativa do StereoCable.
- Colocar o plugue na fila em funcionamento do StereoCable.
- Publicar a informação de que o plugue agora está inativo e desconectado.
- Enviar um evento para o plugue não publicado.
- Se uma nova VM tiver sido descoberta e ela publicar
um soquete ativo solicitado
Essas etapas são descritas neste fluxograma:
Como o StereoCable realiza a inicialização e o processamento dinâmico
(Veja uma imagem maior deste fluxograma.)
A UI e CLI exibem as conexões do StereoCable entre as VMs no datacenter; também fornecem informações detalhadas sobre as conexões estabelecidas e os detalhes dos plugues e soquetes relacionados.
Sobre o processamento dinâmico do StereoCable
Uma vez estabelecidas, as conexões do StereoCable são verdadeiramente dinâmicas devido à capacidade do mecanismo que processa eventos:
- Esse mecanismo é capaz de processar eventos (como, por exemplo, um soquete publicado ou removido) para ativar, remover ou reativar uma conexão.
- O mecanismo também gera eventos quando um soquete é publicado, atualizado ou removido, para notificar a mudança aos usuários.
A Figura 2 mostra como o mecanismo processa eventos.
Figura 2. Processando eventos
Criando uma conexão StereoCable
Nesta seção, iremos descrever as etapas para criar, implementar, estabelecer e verificar uma conexão StereoCable entre dois produtos — o primeiro agindo como um agente e o segundo, como um servidor — instalados em máquinas virtuais diferentes. Este é apenas um exemplo de uma conexão cliente/servidor, mas o StereoCable pode também ser usado para estabelecer conexões de servidor a servidor em cenários de integração complexos.
Definindo uma conexão StereoCable
Uma conexão StereoCable é composta por duas partes, o plugue e o soquete, e é especificada em formato XML. A Listagem 2 mostra a definição da conexão StereoCable:
Listagem 2. Definição da conexão StereoCable em XML
<tns:StereoCablesxmlns:tns="http://ibm.com/stereocables"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://ibm.com/stereocables StereoCables.xsd
"> <StereoCable>
<StereoCableID>AGENT-SERVER</StereoCableID>
<Description>Agent Server
Connection</Description>
<PlugSection> <Description>Agent
Plug</Description>
<PlugID>AGENT</PlugID>
<ConfigurationActions>
<ConfigurationAction>
<Description>Agent
configuration</Description>
<ID>ConfigurationActionID1</ID>
<Trigger>Deployment</Trigger>
<Action>
<ActionType>script</ActionType>
<ActionDetail>
<ConfigurationParameters>
<ConfigurationParameter>
<ConfigurationName>hostname</ConfigurationName>
</ConfigurationParameter>
<ConfigurationParameter>
<ConfigurationName>port</ConfigurationName>
</ConfigurationParameter>
</ConfigurationParameters>
<Operations>
<Operation>agent_config.sh</Operation>
<OS>Linux</OS>
</Operations> </ActionDetail>
</Action> </ConfigurationAction>
</ConfigurationActions>
</PlugSection> <SocketSection>
<Description>Server
Socket</Description>
<SocketID>SERVER</SocketID>
<PublishedParameters>
<ConfigurationParameter>
<ConfigurationName>hostname</ConfigurationName>
<ConfigurationType>ActionBased</ConfigurationType>
<Action>
<ActionType>script</ActionType>
<ActionDetail>
<ConfigurationParameters>
<ConfigurationParameter>
<ConfigurationName>hostname</ConfigurationName>
<ConfigurationValue>hostname</ConfigurationValue>
<ConfigurationType>UserDefined</ConfigurationType>
</ConfigurationParameter>
</ConfigurationParameters>
<Operations>
<Operation>getNetworkConf.sh</Operation>
<OS>Linux</OS>
</Operations> <Operations>
<Operation>getNetworkConf.sh</Operation>
<OS>AIX</OS>
</Operations> </ActionDetail>
</Action> </ConfigurationParameter>
<ConfigurationParameter>
<ConfigurationName>port</ConfigurationName>
<ConfigurationValue>2000</ConfigurationValue>
</ConfigurationParameter>
</PublishedParameters>
</SocketSection> </StereoCable>
</tns:StereoCables> |
Neste exemplo, o plugue é o agente; e o servidor é o soquete.
O PlugSection especifica as ações
executadas pelo agente/plugue para conectar-se ao
servidor/soquete. No exemplo, o script chamado agent_config.sh será executado no
momento da implementação, tomando como entradas o nome do host e
porta publicados pelo soquete.
O SocketSection descreve as
informações publicadas pelo soquete, especificamente o nome do
host e a porta exigidos pelo agente/plugue. Observe que o nome
do host é recuperado dinamicamente executando o script getNetworkConf.sh enquanto a porta é
definida estaticamente no arquivo XML.
O arquivo StereoCables.xml que contém a definição StereoCable será implementado nas máquinas agente e servidor.
Implementando os mecanismos StereoCable
Para implementar os mecanismos, é necessário transferir por download e descompactar os arquivos do Mecanismo StereoCable nos diretórios das máquinas agente e servidor. A Figura 3 mostra isso.
Figura 3. Implementando os mecanismos
Em nosso exemplo, o mecanismo está configurado para usar um tempo de execução Java™ no diretório Java (neste caso, Java 2 Technology Edition, Ambiente de Tempo de Execução de 64 bits Versão 5.0 para Linux® em uma arquitetura AMD64). Se você tiver uma arquitetura diferente, especifique o caminho no arquivo conf/environment.properties. Observe que o mecanismo foi testado com Java 2 Technology Edition, Ambiente de Tempo de Execução de 64 bits Versão 5.0 para Linux em arquitetura AMD64.
Em seguida, copie o arquivo StereoCables.xml no diretório de dados (Figura 4).
Figura 4. Implementando os StereoCables
Especifique as regras de cada máquina no arquivo conf/stereocables.properties.
Figura 5. Definindo as regras
Na máquina servidor, edite a chave dos soquetes de modo que seja
sockets=SERVER. Na máquina
agente, edite a chave dos plugues de modo que seja plugs=AGENT.
Nas máquinas agente e servidor, especifique o mesmo ambiente:
environment=TEST.
Para iniciar os mecanismos, faça uma série de registro deles antes de executá-los.
Para registrar a máquina servidor:
$./vEngine.sh -reg CTJES0003I
Loading configuration. CTJES0004I The configuration has been
successfully loaded. CTJES0001I Executing the operation:
Registering the engine. CTJES0002I Operation successfully
executed: Registering the engine. |
Para executar a máquina servidor:
$./vEngine.sh -run CTJES0003I
Loading configuration. CTJES0004I The configuration has been
successfully loaded. CTJES0001I Executing the operation: Run the
engine. CTJES0001I Executing the operation: Cable processing.
CTJES0005I Processing socket: SERVER. CTJES0011I Publishing
information. CTJES0013I Sending event: Socket SERVER published.
CTJES0019I Processing event's type:
STEREOCABLES_SOCKET_PUBLISHED.SERVER. CTJES0020I Event
processed. CTJES0006I Socket SERVER successfully processed.
Socket processed: SERVER: Success Plug processed: CTJES0002I
Operation successfully executed: Cable processing. |
Para registrar o mecanismo agente:
$./vEngine.sh -reg CTJES0003I
Loading configuration. CTJES0004I The configuration has been
successfully loaded. CTJES0001I Executing the operation:
Registering the engine. CTJES0002I Operation successfully
executed: Registering the engine. |
Para executar o mecanismo agente:
$$./vEngine.sh -run CTJES0003I
Loading configuration. CTJES0004I The configuration has been
successfully loaded. CTJES0001I Executing the operation: Run the
engine. CTJES0001I Executing the operation: Cable processing.
CTJES0005I Processing plug: AGENT. CTJES0011I Publishing
information. CTJES0013I Sending event: plug AGENT published.
CTJES0019I Processing event's type:
STEREOCABLES_PLUG_PUBLISHED.AGENT. CTJES0020I Event processed.
CTJES0006I Plug AGENT successfully processed. Socket processed:
Plug processed: AGENT: Success CTJES0002I Operation successfully
executed: Cable processing. |
É possível listar as informações publicadas e as conexões
StereoCable disponíveis no ambiente executando o comando $script/Cli.sh -list.
CTJES0003I Loading configuration.
CTJES0004I The configuration has been successfully loaded.
CTJES0001I Executing the operation: Discovery machines.
CTJES0002I Operation successfully executed: Discovery machines.
-------------------------------------------------------------------
srv.ivm.com
-------------------------------------------------------------------
guestInfo.stereocables.env = TEST guestInfo.stereocables.status
= Enabled guestInfo.stereocables.sockets = SERVER
guestInfo.stereocables.socket.SERVER.status=Active
guestInfo.stereocables.socket.SERVER.hostname=srv.ivm.com
guestInfo.stereocables.socket.SERVER.port=2000
guestInfo.stereocables.plugs =
-------------------------------------------------------------------
-------------------------------------------------------------------
agt.ivm.com
-------------------------------------------------------------------
guestInfo.stereocables.env = TEST guestInfo.stereocables.status
= Enabled guestInfo.stereocables.sockets =
guestInfo.stereocables.plugs = AGENT
guestInfo.stereocables.plug.AGENT.status=Active
guestInfo.stereocables.plug.AGENT.connected=srv.ivm.com:SERVER
------------------------------------------------------------------- |
Como você pode ver, no ambiente TEST,
a máquina agt.ivm.com está plugada em srv.ivm.com.
Nós tivemos o prazer de lhe mostrar um novo conceito — uma maneira pela qual máquinas virtuais em um datacenter virtual podem descobrir e conectar automaticamente umas às outras baseado em políticas de conexão predefinidas — e apresentamos um projeto no qual estamos trabalhando que você pode usar para ativar um sistema assim.
Lembre-se, dispositivos virtuais tem o poder de alterar a maneira como o software é distribuído, pois podem dar aos construtores de aplicativos a capacidade de otimizar sua pilha de software para aplicativos e oferecer ao usuário final um serviço de software pronto para uso. Uma etapa essencial para conseguir esse nível de serviço em um aplicativo na nuvem é automatizando, e assim aprimorando, as conexões de máquina virtual.
| Descrição | Nome | Tamanho | Método de download |
|---|---|---|---|
| Sample code for this article | stereocable.zip | 10KB | HTTP |
Informações sobre métodos de download
Aprender
- O site IBM Smart Business Development and Test on the IBM
Cloud é seu lugar para ver como começar a desenvolver
seus aplicativos para a nuvem.
- Consulte a lista crescente de imagens de software disponíveis no IBM
Cloud.
- Nos recursos para desenvolvedores de nuvem do
developerWorks, descubra e compartilhe o conhecimento e
a experiência dos desenvolvedores de aplicativos e serviços que
estão desenvolvendo os seus projetos de implementação de nuvem.
Discutir
- Participe de um grupo sobre computação em nuvem no My developerWorks.
- Leia todos os ótimos blogs sobre nuvem no My developerWorks.
- Participe dos comunidade do My developerWorks uma rede profissional e
conjunto de ferramentas comunitárias para conectar, compartilhar
e colaborar.
Giuseppe Ciano passou a fazer parte da IBM em 1997 como engenheiro de software no SWG Tivoli Lab de Roma. Ele trabalha há 11 anos como desenvolvedor e designer de diferentes produtos no portfólio Tivoli. É atualmente designer chefe de Soluções em Nuvem Tivoli, como o produto IBM Service Delivery Manager. Também é o designer do StereoCable.
Maurizio Simeoni formou-se em engenharia de telecomunicações na Universidade de Roma "La Sapienza". É engenheiro da equipe IBM Tivoli em Roma. Atualmente, ele trabalha no IBM Service Delivery Manager. Tem mais de 10 anos de experiência no desenvolvimento e suporte a aplicativos de software. Contribuiu para o design e desenvolvimento do StereoCable.
Alessio D'Amico passou a fazer parte da IBM em 1999 como engenheiro de software do SWG Lab em Roma. Durante sua carreira, ele ganhou experiência em todo o ciclo de vida do projeto, de gerenciamento de projeto, análise de negócios, design e construção até implementação. Atualmente, é responsável por projetar e implementar as soluções de gerenciamento de serviço e computação em nuvem baseadas no portfólio de produtos Tivoli. Suas principais áreas de conhecimento incluem gerenciamento de sistemas, fornecimento, gerenciamento de serviço, virtualização e computação em nuvem.
Antonio Perrone formou-se com mérito em ciências da informação na Universidade de Bari, na Itália, em 1989. Ele passou a fazer parte da IBM em 1990, e ocupou várias posições em desenvolvimento e suporte. Ele está na divisão IBM Tivoli desde 1996, na qual é atualmente arquiteto da área de gerenciamento de desempenho de rede. Seus interesses incluem gerenciamento de sistemas, desempenho e disponibilidade, representação do conhecimento, integração de dados, transação e modelagem de processo e desenvolvimento de software.
Índice
Conheça a IBM da sua cidade
Tags
Use a barra de rolagem para ver mais ou menos tags.
Tags populares mostra as principais tags para esta zona de conteúdo em particular (por exemplo, Java technology, Linux, WebSphere).
Minhas tags mostra suas tags para esta zona de conteúdo em particular (por exemplo, Java technology, Linux, WebSphere).
Tags de artigo populares |
Minhas tags de artigoIr para lista de tags
Tags de artigo populares |
Minhas tags de artigo