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, seja em um ou mais computadores – 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 softwares executados 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.
• 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 é usada 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, a VM precisa ser sincronizada entre os hosts ou ser armazenada externamente. A abordagem mais robusta 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 aos arquivos geralmente é realizado via protocolo NFS ou CIFS.
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: Desacopla os dados que estão no arquivo e a sua localização, isto é, onde os arquivos estão fisicamente armazenados. Isto proporciona oportunidades para otimizar o uso do armazenamento e a consolidação do servidor para realizar migrações de arquivos sem interrupções.
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. PRODUTOS ELIPSE
Os produtos Elipse Software são normalmente licenciados através de um controle por meio de uma chave de hardware – HASP USB hardkey ou softkey.
Hipervisores comerciais geralmente não suportam um mapeamento estável de uma porta USB de um host físico diretamente para uma VM. Desta forma, para uso em ambientes virtualizados, recomendamos o uso de softkeys, o que deve ser informado no momento da aquisição da licença ou caso já exista uma licença em hardkey, ela pode ser substituída por uma softkey.
Os produtos Elipse Software são compatíveis com diversos Hipervisores, tendo sido testados até Dez/2019 com Microsoft Hyper-V (Windows 10, Server 2008,2012,2016,2019) e VMWare (ESX 4, 5, 6.X).
4.1 Geração de softkey
O software de geração de softkey é fornecido mediante solicitação. Este procedimento gera uma pré-chave de produto baseada na informação da máquina. Esta pré-chave é enviada à Elipse Software, que por sua vez retorna a programação da chave a ser instalada no computador.
Informações importantes:
– A softkey é gerada pela Elipse Software apenas uma vez. Antes de enviar a pré-chave 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 proteção mais adequado, sempre informe a Elipse Software sobre qual arquitetura será utilizada.
4.2 Verificação Periódica e Upgrade
Todas as 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 chave de produto 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 chaves de produto 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 chave de produto 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:
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
Artigos Relacionados
