Elipse Knowledgebase



Guia de Virtualização - Elipse Software.

1. INTRODUÇÃO

A virtualização é a maneira mais eficaz de reduzir custos em TI de modo ágil e eficiente em empresas de qualquer tamanho, já que permite executar múltiplos sistemas operacionais e aplicações em um único computador – deste modo consolidando o hardware para que obtenha maior produtividade em menos servidores.

A virtualização de Hardware se refere à criação de uma máquina virtual (VM) que funciona como um computador real com um sistema operacional. O software executado nestas máquinas virtuais é separado dos recursos de hardware subjacentes.


Figura 1 - Virtualização


Na virtualização de hardware, a  host machine é a máquina física onde a virtualização acontece, e a guest machine é a máquina virtual. As palavras host e guest (anfitrião e convidado, respectivamente) são usadas para distinguir o software executado na máquina física dos software executado na máquina virtual. O software no firmware que cria a máquina virtual no hardware host é chamado de hipervisor ou Gerente de Máquina Virtual.

2. HIPERVISORES

Em seu artigo "Formal Requirements for Virtualizable Third Generation Architectures" de 1974, Gerald J. Popek e Robert P. Goldberg classificam dois tipos de hipervisores:

Tipo 1 (nativo, ou bare metal): são hipervisores que  são executados diretamente no hardware host para controlar o hardware e gerenciar sistemas operacionais convidados, que são executados em um nível superior ao hipervisor. 
Exemplos de hipervisores do Tipo 1 são Oracle VM Server for SPARC, Oracle VM Server for x86, Citrix XenServer, VMware ESX/ESXi e Microsoft Hyper-V 2008/2012.

Tipo 2 (ou hosted): são hipervisores que são executados em um ambiente de Sistema operacional convencional.  Com a camada do hipervisor funcionando como um segundo nível de software distinto, sistemas operacionais convidados são executados em um terceiro nível acima do hardware. VMware Workstation e VirtualBox são exemplos de hipervisores do Tipo 2.


Figura 2 - Hipervisores

3. FUNCIONAMENTO

Uma das vantagens da virtualização é que ela permite que haja mais aplicações em menos servidores. Uma das desvantagens é que a disponibilidade destes servidores se torna mais importante, já que qualquer falha em um deles pode indisponibilizar dezenas de sistemas ou aplicações.

Como a virtualização aposta mais fichas em menos servidores, princípios como alta disponibilidade (High Availability, ou HA) requerem mais atenção. Há uma variedade de abordagens utilizadas para manter as aplicações em execução de modo non-stop.

3.1 Agrupamento

Como uma VM pode sobreviver a falhas em seu hipervisor host ou em seu servidor físico? A solução envolve agrupar hipervisores através de múltiplos servidores físicos para que, no caso de falha em algum deles, as VMs ativas sejam transferidas para outro servidor.

Mensagens heartbeat são passadas entre hipervisores agrupados e uma Metodologia de Infraestrutura Virtual (MIV) central para manter o status de monitoração.  O armazenamento compartilhado é fornecido para hipervisores agrupados e posteriormente utilizado para armazenar discos de servidores virtuais.

 
Figura 3 - Clustering

3.2 Armazenamento compartilhado

Como uma VM em um agrupamento pode ser movida entre diferentes host físicos, e também porque host físicos podem cair e portanto ficarem inacessíveis, os dados não podem ser armazenados localmente em cada servidor. A abordagem correta para manter a informação segura e acessível ao mesmo tempo é adicionar um Armazenamento Compartilhado ao agrupamento, também conhecido como “Storage Array” ou “Disk Array”.

Sistemas de armazenamento normalmente utilizam hardware e software especiais juntamente com drives de discos, a fim de fornecer um armazenamento bastante rápido e confiável para a computação e o processamento de dados.  Sistemas de armazenamento são complexos, e podem ser pensados como um computador com propósitos especiais projetados para fornecer capacidade de armazenamento juntamente com recursos de proteção avançada de dados. Drives de disco são apenas um dos elementos em um sistema de armazenamento, juntamente com o hardware e com softwares para propósitos especiais embutidos dentro do sistema.
Sistemas de armazenamento podem fornecer armazenamento por acesso em bloco ou por acesso em arquivos.  O acesso em bloco é tipicamente feito via Fibre Channel, iSCSI, SAS, FICON ou outros protocolos. O acesso em arquivo é normalmente feito via NFS ou CIFS protocolos.
Dentro do contexto de um sistema de armazenamento, há normalmente dois tipos básicos de visualização que podem ocorrer:

• Virtualização em bloco: utilizada neste contexto, refere-se à abstração (separação) do armazenameento lógico (partição) do armazenamento físico para que ele possa ser acessado sem consideração ao armazenamento físico ou à estrutura heterogênea. Esta separação permite aos administradores do sistema de armazenamento uma maior flexibilidade no gerenciamento de usuários finais.[1]

• Virtualização em arquivos: visa os desafios NAS ao eliminar as dependências entre os dados acessados a nível de arquivo e o local onde os arquivos estão armazenados fisicamente. Isto proporciona oportunidades para otimizar o uso do armazenamento e a consolidação do servidor e parar realizar migrações de arquivos não desruptivas.

3.2.1 RAID

Um sistema de armazenamento normalmente utiliza uma tecnologia que combina múltiplos componentes de drives de discos em uma unidade lógica para os propósitos de redundância de dados e melhorias na performance. A isto é dado o nome de Conjunto Redundante de Discos Independentes, ou Redundant Array of Independent Disks (RAID). Os dados são distribuídos através dos drives em um dos vários Níveis RAID, dependendo do nível específico de redundância e performance exigidos.

Para maiores informações, visite http://pt.wikipedia.org/wiki/RAID.

3.3 Alta Disponibilidade (High Availability)

A HA (High Availability) confere a saúde das máquinas virtuais e detecta quaisquer problemas nesta area. Se alguma falha de sistema operacional for detectada, o hipervisor automaticamente reinicializa a máquina virtual. Se o servidor físico subjacente de uma máquina virtual cair, ele reiniciará a aplicação em outro servidor físico. 

3.4 Tolerância a Falhas (Fault Tolerance)

Enquanto a HA envolve o reboot de máquinas virtuais (e o respectivo downtime), a Fault Tolerance (FT) contorna o problema ao permitir que os clientes executem uma “instância sombra” de uma VM de produção que é mantida em sincronia com a instância principal.

A instância sombra assumirá o controle imediatamente se algo acontecer à maquina virtual de produção, sem a necessidade de reinicializar.

No entanto, este procedimento consume recursos adicionais, já que a FT é efetivamente um método de espelhamento, então a habilitação desta tecnologia envolve dobrar o volume de hardware.

4. LICENCIAMENTO ELIPSE

Os produtos Elipse Software são normalmente licenciados através de um hardware key - HASP USB hardkey.

Hipervisores comerciais geralmente não suportam um mapeamento estável de uma porta USB de um host físico diretamente para uma VM. Porém, em uma plataforma de testes interna, utilizamos o dispositivo hub USB AnywhereUsb/14 do fornecedor Digi (http://www.digi.com/products/usb-and-serial-connectivity/usb-over-ip-hubs/anywhereusb) em rede local (padrão Lan 100 mbps) com interface e fonte redundantes, que tem se mostrado confiável e estável em nossas aplicações - com retorno positivo de outros clientes que utilizam o mesmo dispositivo (ou similar) deste fabricante.

O VMWare é na verdade o único hipervisor que suporta este recurso nativamente. No entanto, cada Elipse Virtual Machine deve ser configurada com a HA/FT desativadas e conectada a um servidor físico fixo ao qual a hardkey esteja ligada. 

Para outros hipervisores, ou para quando a HA/FT em VMWare for necessária, o mais indicado é o uso da licença softkey.

4.1 Geração de softkey

O software de geração de softkey é fornecido mediante solicitação. Este procedimento gera uma pré-licença baseada na informação da máquina. Este pré-licença é enviada à Elipse Software, que por sua vez retorna a licença a ser instalada no computador.

Informações importantes:

- As licenças de softkey são geradas pela Elipse Software apenas uma vez. Antes de enviar a pré-licença para a Elipse, certifique-se de que ela está coletada na VM definitiva que está sendo executada no host correto.

- Por favor, para a identificação do tipo de licenciamento mais adequado, sempre informe a Elipse Software sobre qual arquitetura será utilizada.

4.2 Verificação Periódica e Upgrade

Todas as licenças de softkey possuem uma data de expiração, e devem portanto ser reprogramadas periodicamente. Existem dois procedimentos disponíveis para o Upgrade: Elipse license manager (ELIC) e upgrade manual.

4.2.1 Elipse License Manager

Oferece uma ferramenta de upgrade automática pela internet. Com o Elic, um computador em um DMZ da rede do sistema pode receber um upgrade em tempo hábil e transferi-lo à VM ou às máquinas físicas onde a softkey ou a hardkey estejam instaladas.

A Elipse Software também pode enviar emails ou alertas sempre que uma licença estiver perto de sua data de expiração ou sempre que um procedimento de upgrade houver falhado.



Figura 4 - Elipse License Manager


4.2.2 Upgrade Manual

Pode ser utilizado quando não houver conexão de internet disponível, ou se por algum outro motivo o upgrade não puder ser feito pelo Elic.

5. ELIPSE E3 E POWER – ARQUITETURAS POSSÍVEIS

5.1 Redundância

Os sistemas Elipse E3 e Elipse Power SCADA possuem seus próprios gerenciamentos de redundância. Para utilizá-los, serão necessárias duas licenças em cada Servidor, cada uma delas configurada como uma VM diferente. Então, nas opções de configuração do Domínio do E3, as configurações da VM serão definidas, bem como outros perfis de redundância e opções de configuração. Normalmente, a  redundância do domínio nativo é capaz de ser ativa (ou de se recuperar de um servidor com failover) entre 2 e 30 segundos em média, dependendo do tamanho da aplicação e de sua configuração.

No entanto, a HA e a FT oferecem opções de redundância diferentes, que podem ser utilizadas independentemente da redundância nativa do E3.

A HA permite reiniciar uma única VM no caso da detecção de falhas no hardware ou no sistema operacional, e não de falhas internas do software. Neste caso, você terá apenas uma licença de E3 em uma única VM, que é destruída e reiniciada do início. Mesmo quando um  host físico cai, a HA pode reinicializar a VM em outro host em cerca de 30 a 60 segundos em média.

A HA também pode ser utilizada juntamente com a redundância nativa do E3, o que faz deste um esquema de quad-redundância, conforme a figura abaixo:


Figura 5 - High Availability

Alguns hipervisores podem também carregar a HA separadamente, dependendo do número de CPUs virtuais (vCPUs) na VM.

Já a FT, por sua vez, basicamente evita o tempo de startup HA/VM a custo de rede e CPU, deixando a segunda VM bloqueada com uma VM primária. Em outras palavras, a FT é capaz de substituir o sistema de redundância nativo do E3, embora tenha sido desenvolvida para superar apenas falhas no hardware, assim como a HA.  De qualquer modo, a FT ainda pode ser utilizada em conjunto com a redundância nativa do E3 a fim de prevenir falhas tanto a nível de hardware, SO, e software de aplicação.


Figura 6 - Fault Tolerance

No entanto, em caso de falhas apenas no hardware, esta arquitetura pode nunca fazer um switchover para o  E3 Server VM2 Stby utilizando redundância nativa, porque a detecção de FT provavelmente acontecerá primeiro.


5.2 Arquivos e Bibliotecas do Projeto

Os bancos de dados e arquivos dos projetos do Elipse E3 e do Elipse Power (PRJ e LIB) devem ser mantidas em ambos os servidores, caso a redundância nativa esteja sendo utilizada (ou seja, em ambas as VMs). Para que o E3 Studio configure uma aplicação sendo executada, ele deve ter  acesso de rede aos servidores e aos arquivos de banco de dados, que podem ser declarados no Domínio E3  através de um atalho de rede (ex: \\MACHINE1\Application) ou de um atalho compartilhado de rede (como um diretório F:\ ou G:\, por exemplo).

No entanto, tanto um hipervisor quanto uma ferramenta do Windows Server chamada DFS (Distributed File System) podem ser utilizados para simplificar a sincronização de banco de dados entre as VMs e o acesso ao E3 Studio. Com o DFS, uma rede em comum ou um folder de compartilhamento podem ser declarados identicamente em ambos os servidores e também em outras máquinas, como o E3 Studio. Embora para cada máquina os atalhos pareçam ser independentes mas com o mesmo nome, o DFS na verdade procura sincronizar todos os arquivos de folder automaticamente entre todos os parceiros, replicando as mudanças quando estas acontecem.

 
Figura 7 - Sistemas de Arquivos Distribuídos

A fim de permitir que a sincronização aconteça enquanto os processos principais estejam sendo executados, o E3 versão 4.5 introduz um recurso especial chamado “Hands-Off Mode”, que permite mundaças em tempo de execução em arquivos de projeto, que devem ser habilitados a ser usados com o DFS, se possível.

5.3 Banco de Dados

A redundância nativa do E3 é capaz de sincronizar bancos de dados históricos de dados de processo (SQL ou Oracle). Entretanto, isto não faz sentido em um ambiente virtualizado, já que arquivos de bancos de dados podem ser armazenados em discos externos, e não dentro de cada VM. Por isso, por motivos práticos, a sincronização de banco de dados nativo deve ser desabilitada.

A abordagem mais recomendada para uma Aplicação E3 virtualizada é desenvolver uma VM independente para o mecanismo de software de banco de dados (a VM onde são instalados o SQL Server ou o software Oracle) e colocar os arquivos de dados do DB diretamente nos discos externos, onde a informação estará mais segura graças ao esquema RAID.

6. ELIPSE PLANT MANAGER

A arquitetura recomendada para o Elipse Plant Manager (EPM) depende de um armazenamento seguro para os arquivos correntes e de backups definidos pelo usuário para arquivos mais antigo.  Para uma melhor performance, siga estes procedimentos:

a) Defina uma VM para o sistema SQL Server, com a HA caso esteja disponível.
b) Defina uma VM para o EPM Server, com HA/FT caso estejam disponíveis.
c) Durante a configuração do  EPM Database, crie atalhos diferentes para os arquivos Database e Log, com cada atalho representando diferentes discos físicos/volumes. Isto aumenta a capacidade de E/S do sistema.
d) Instale o Interface Server nas origens de dados locais.

7 REFERÊNCIAS

http://www.vmware.com/virtualization/virtualization-basics/what-is-virtualization.html
http://en.wikipedia.org/wiki/Hypervisor 
http://www.cio.com/article/732479/
http://cloudpatterns.org/design_patterns/hypervisor_clustering
Manual do Usuário do Elipse E3, versão 4.5
Manual do Usuário do Elipse Plant Manager, versão 2.0

SalvarSalvar


Artigos Relacionados

Anexos

Este artigo não possui anexos.

Comentários de Usuários

Nenhum comentário de usuário. Adicionar um comentário

Comentários do artigo 'Guia de Virtualização - Elipse Software.'

Para adicionar um comentário neste artigo, preencha os campos abaixo. Os campos marcados com asterisco são obrigatórios.

   Nome:
   E-mail:
* Comentário:
* Digite o código abaixo:

 

Detalhes do Artigo

Última Atualização
1st of December, 2016

Autor
Marcelo Salvador

Você gostaria de...

Imprimir esta página  Imprimir esta página

Enviar por e-mail esta página  Enviar por e-mail esta página

Adicionar um comentário  Adicionar um comentário

 Avise-me

Avise-me  Adicionar aos favoritos

Remover Marcação Remover Marcação

Editar este Artigo

Edição Rápida


Opinião dos Usuários

100% thumbs up 0% thumbs down (5 Votos)

Como você classifica este artigo?




Obrigado pelo seu voto.

Continuar