{"id":3330,"date":"2019-03-25T17:43:47","date_gmt":"2019-03-25T20:43:47","guid":{"rendered":"http:\/\/xexeu.elipse.com.br\/pt\/guia-de-virtualizacao-elipse-software\/"},"modified":"2024-09-04T11:26:41","modified_gmt":"2024-09-04T14:26:41","slug":"guia-de-virtualizacao-elipse-software","status":"publish","type":"post","link":"https:\/\/kb.elipse.com.br\/en\/guia-de-virtualizacao-elipse-software\/","title":{"rendered":"Guia de Virtualiza\u00e7\u00e3o – Elipse Software."},"content":{"rendered":"

1. INTRODU\u00c7\u00c3O<\/strong><\/span><\/p>\n

A virtualiza\u00e7\u00e3o<\/strong> \u00e9 a maneira mais eficaz de reduzir custos em TI de modo \u00e1gil e eficiente em empresas de qualquer tamanho, j\u00e1 que permite executar m\u00faltiplos sistemas operacionais e aplica\u00e7\u00f5es,\u00a0seja em um ou mais computadores \u2013 deste modo consolidando o hardware para que obtenha maior produtividade em menos servidores.<\/p>\n

A virtualiza\u00e7\u00e3o de Hardware se refere \u00e0 cria\u00e7\u00e3o de uma m\u00e1quina virtual (VM) que funciona como um computador real com um sistema operacional. O software executado nestas m\u00e1quinas virtuais \u00e9 separado dos recursos de hardware subjacentes.<\/p>\n

\"\"
\nFigura 1 – Virtualiza\u00e7\u00e3o<\/p>\n

Na virtualiza\u00e7\u00e3o de hardware, a\u00a0 host machine \u00e9 a m\u00e1quina f\u00edsica onde a virtualiza\u00e7\u00e3o acontece, e a guest machine \u00e9 a m\u00e1quina virtual. As palavras host e guest (anfitri\u00e3o e convidado, respectivamente<\/em>) s\u00e3o usadas para distinguir o software executado na m\u00e1quina f\u00edsica dos softwares executados na m\u00e1quina virtual. O software no firmware que cria a m\u00e1quina virtual no hardware host \u00e9 chamado de hipervisor <\/em>ou Gerente de M\u00e1quina Virtual.<\/p>\n

2. HIPERVISORES<\/strong><\/span><\/p>\n

Em seu artigo “Formal Requirements for Virtualizable Third Generation Architectures” de 1974, Gerald J. Popek e Robert P. Goldberg classificam dois tipos de hipervisores:<\/p>\n

\u2022 Tipo 1<\/strong> (nativo, ou bare metal): s\u00e3o hipervisores que\u00a0 s\u00e3o executados diretamente no hardware host para controlar o hardware e gerenciar sistemas operacionais convidados, que s\u00e3o executados em um n\u00edvel superior ao hipervisor.
\nExemplos de hipervisores do Tipo 1 s\u00e3o Oracle VM Server for SPARC, Oracle VM Server for x86, Citrix XenServer, VMware ESX\/ESXi e Microsoft Hyper-V.
\n<\/strong>
\n\u2022 Tipo 2<\/strong> (ou hosted): s\u00e3o hipervisores que s\u00e3o executados em um ambiente de Sistema operacional convencional.\u00a0 Com a camada do hipervisor funcionando como um segundo n\u00edvel de software distinto, sistemas operacionais convidados s\u00e3o executados em um terceiro n\u00edvel acima do hardware. VMware Workstation e VirtualBox<\/strong> s\u00e3o exemplos de hipervisores do Tipo 2.<\/p>\n

\"\"
\nFigura\u00a02 –\u00a0Hipervisores<\/p>\n

3. FUNCIONAMENTO<\/span><\/strong><\/p>\n

Uma das vantagens da virtualiza\u00e7\u00e3o \u00e9 que ela permite que haja mais aplica\u00e7\u00f5es em menos servidores. Uma das desvantagens \u00e9 que a disponibilidade destes servidores se torna mais importante, j\u00e1 que qualquer falha em um deles pode indisponibilizar dezenas de sistemas ou aplica\u00e7\u00f5es.<\/p>\n

Como a virtualiza\u00e7\u00e3o aposta mais fichas em menos servidores, princ\u00edpios como alta disponibilidade (High Availability, ou HA) requerem mais aten\u00e7\u00e3o. H\u00e1 uma variedade de abordagens utilizadas para manter as aplica\u00e7\u00f5es em execu\u00e7\u00e3o de modo non-stop.<\/p>\n

3.1 Agrupamento<\/strong><\/span><\/p>\n

Como uma VM pode sobreviver a falhas em seu hipervisor host ou em seu servidor f\u00edsico? A solu\u00e7\u00e3o envolve agrupar hipervisores atrav\u00e9s de m\u00faltiplos servidores f\u00edsicos para que, no caso de falha em algum deles, as VMs ativas sejam transferidas para outro servidor.<\/p>\n

Mensagens heartbeat s\u00e3o passadas entre hipervisores agrupados e uma Metodologia de Infraestrutura Virtual (MIV) central \u00e9 usada para manter o status de monitora\u00e7\u00e3o.\u00a0 O armazenamento compartilhado \u00e9 fornecido para hipervisores agrupados e posteriormente utilizado para armazenar discos de servidores virtuais.<\/p>\n

\"\"
\nFigura\u00a03 –\u00a0Clustering<\/p>\n

3.2 Armazenamento compartilhado<\/strong><\/span><\/p>\n

Como uma VM em um agrupamento pode ser movida entre diferentes host f\u00edsicos, e tamb\u00e9m porque host f\u00edsicos podem cair e portanto ficarem inacess\u00edveis, a VM precisa\u00a0ser sincronizada\u00a0entre os hosts ou ser armazenada externamente. A abordagem mais robusta para manter a informa\u00e7\u00e3o segura e acess\u00edvel ao mesmo tempo \u00e9 adicionar um Armazenamento Compartilhado ao agrupamento, tamb\u00e9m conhecido como \u201cStorage Array\u201d ou \u201cDisk Array\u201d.<\/p>\n

Sistemas de armazenamento normalmente utilizam hardware e software especiais juntamente com drives de discos, a fim de fornecer um armazenamento bastante r\u00e1pido e confi\u00e1vel para a computa\u00e7\u00e3o e o processamento de dados.\u00a0 Sistemas de armazenamento s\u00e3o complexos, e podem ser pensados como um computador com prop\u00f3sitos especiais projetados para fornecer capacidade de armazenamento juntamente com recursos de prote\u00e7\u00e3o avan\u00e7ada de dados. Drives de disco s\u00e3o apenas um dos elementos em um sistema de armazenamento, juntamente com o hardware e com softwares para prop\u00f3sitos especiais embutidos dentro do sistema.
\nSistemas de armazenamento podem fornecer armazenamento por acesso em bloco ou por acesso em arquivos.\u00a0 O acesso em bloco \u00e9 tipicamente feito via Fibre<\/strong> Channel<\/strong>, iSCSI<\/strong>, SAS<\/strong>, FICON<\/strong> ou outros protocolos. O acesso aos arquivos geralmente \u00e9 realizado via protocolo NFS<\/strong> ou CIFS<\/strong>.
\nDentro do contexto de um sistema de armazenamento, h\u00e1 normalmente dois tipos b\u00e1sicos de visualiza\u00e7\u00e3o que podem ocorrer:<\/p>\n

\u2022 Virtualiza\u00e7\u00e3o em bloco:<\/strong> utilizada neste contexto, refere-se \u00e0 abstra\u00e7\u00e3o (separa\u00e7\u00e3o) do armazenameento l\u00f3gico (parti\u00e7\u00e3o) do armazenamento f\u00edsico para que ele possa ser acessado sem considera\u00e7\u00e3o ao armazenamento f\u00edsico ou \u00e0 estrutura heterog\u00eanea. Esta separa\u00e7\u00e3o permite aos administradores do sistema de armazenamento uma maior flexibilidade no gerenciamento de usu\u00e1rios finais.[1]
\n<\/span>
\n\u2022 Virtualiza\u00e7\u00e3o em arquivos:<\/strong> Desacopla os dados que est\u00e3o no arquivo e a sua localiza\u00e7\u00e3o, isto \u00e9, onde os arquivos est\u00e3o fisicamente armazenados. Isto proporciona oportunidades para otimizar o uso do armazenamento e a consolida\u00e7\u00e3o do servidor para realizar migra\u00e7\u00f5es de arquivos sem interrup\u00e7\u00f5es.<\/p>\n

3.2.1\u00a0RAID<\/strong><\/span><\/p>\n

Um sistema de armazenamento normalmente utiliza uma tecnologia que combina m\u00faltiplos componentes de drives de discos em uma unidade l\u00f3gica para os prop\u00f3sitos de redund\u00e2ncia de dados e melhorias na performance. A isto \u00e9 dado o nome de Conjunto Redundante de Discos Independentes, ou Redundant Array of Independent Disks (RAID). Os dados s\u00e3o distribu\u00eddos atrav\u00e9s dos drives em um dos v\u00e1rios N\u00edveis RAID, dependendo do n\u00edvel espec\u00edfico de redund\u00e2ncia e performance exigidos.<\/p>\n

Para maiores informa\u00e7\u00f5es, visite http:\/\/pt.wikipedia.org\/wiki\/RAID<\/a>.<\/p>\n

3.3 Alta Disponibilidade (High Availability)<\/strong><\/span><\/p>\n

A HA (High Availability) confere a sa\u00fade das m\u00e1quinas virtuais e detecta quaisquer problemas nesta area. Se alguma falha de sistema operacional for detectada, o hipervisor automaticamente reinicializa a m\u00e1quina virtual. Se o servidor f\u00edsico subjacente de uma m\u00e1quina virtual cair, ele reiniciar\u00e1 a aplica\u00e7\u00e3o em outro servidor f\u00edsico.<\/p>\n

3.4 Toler\u00e2ncia a Falhas (Fault Tolerance)<\/strong><\/span><\/p>\n

Enquanto a HA envolve o reboot de m\u00e1quinas virtuais (e o respectivo downtime), a Fault Tolerance (FT) contorna o problema ao permitir que os clientes executem uma \u201cinst\u00e2ncia sombra\u201d de uma VM de produ\u00e7\u00e3o que \u00e9 mantida em\u00a0sincronia com a inst\u00e2ncia principal.<\/p>\n

A inst\u00e2ncia sombra assumir\u00e1 o controle imediatamente se algo acontecer \u00e0 maquina virtual de produ\u00e7\u00e3o, sem a necessidade de reinicializar.<\/p>\n

No entanto, este procedimento consume recursos adicionais, j\u00e1 que a FT \u00e9 efetivamente um m\u00e9todo de espelhamento, ent\u00e3o a habilita\u00e7\u00e3o desta tecnologia envolve dobrar o volume de hardware.<\/p>\n

4. PRODUTOS ELIPSE<\/strong><\/span><\/p>\n

Os produtos Elipse Software s\u00e3o normalmente licenciados atrav\u00e9s de um controle por meio de uma chave de hardware \u2013 HASP USB hardkey ou softkey.<\/p>\n

Hipervisores comerciais geralmente n\u00e3o suportam um mapeamento est\u00e1vel de uma porta USB de um host f\u00edsico 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\u00e7\u00e3o da licen\u00e7a ou caso j\u00e1 exista uma licen\u00e7a em hardkey, ela pode ser substitu\u00edda por uma softkey.<\/p>\n

Os produtos Elipse Software s\u00e3o compat\u00edveis com diversos Hipervisores, tendo sido testados at\u00e9 Dez\/2019 com Microsoft Hyper-V (Windows 10, Server 2008,2012,2016,2019) e VMWare (ESX 4, 5, 6.X).<\/p>\n

4.1 Gera\u00e7\u00e3o de softkey<\/span> <\/strong><\/p>\n

O software de gera\u00e7\u00e3o de softkey \u00e9 fornecido mediante solicita\u00e7\u00e3o. Este procedimento gera uma pr\u00e9-chave de produto baseada na informa\u00e7\u00e3o da m\u00e1quina. Esta pr\u00e9-chave \u00e9 enviada \u00e0 Elipse Software, que por sua vez retorna a programa\u00e7\u00e3o da chave a ser instalada no computador.<\/p>\n

Informa\u00e7\u00f5es importantes:<\/strong><\/p>\n

–\u00a0A softkey \u00e9 gerada pela Elipse Software apenas uma vez. Antes de enviar a pr\u00e9-chave para a Elipse, certifique-se de que ela est\u00e1 coletada na VM definitiva que est\u00e1 sendo executada no host correto.<\/p>\n

– Por favor, para a identifica\u00e7\u00e3o do tipo de prote\u00e7\u00e3o mais adequado, sempre informe a Elipse Software sobre qual arquitetura ser\u00e1 utilizada.<\/p>\n

4.2 Verifica\u00e7\u00e3o Peri\u00f3dica e Upgrade<\/strong><\/span><\/p>\n

Todas as softkey possuem uma data de expira\u00e7\u00e3o, e devem portanto ser reprogramadas periodicamente. Existem dois procedimentos dispon\u00edveis para o Upgrade:\u00a0Elipse license manager (ELIC) e upgrade manual.<\/p>\n

4.2.1 Elipse License Manager<\/strong><\/span><\/p>\n

Oferece uma ferramenta de upgrade autom\u00e1tica pela internet. Com o Elic, um computador em um DMZ da rede do sistema pode receber um upgrade em tempo h\u00e1bil e transferi-lo \u00e0 VM ou \u00e0s m\u00e1quinas f\u00edsicas onde a softkey ou a hardkey estejam instaladas.<\/p>\n

A Elipse Software tamb\u00e9m pode enviar emails ou alertas sempre que uma chave de produto estiver perto de sua data de expira\u00e7\u00e3o ou sempre que um procedimento de upgrade houver falhado.<\/p>\n

\"\"
\nFigura\u00a04 –\u00a0Elipse License Manager<\/p>\n

4.2.2 Upgrade Manual<\/strong><\/span><\/p>\n

Pode ser utilizado quando n\u00e3o houver conex\u00e3o de internet dispon\u00edvel, ou se por algum outro motivo o upgrade n\u00e3o puder ser feito pelo Elic.<\/p>\n

5. ELIPSE E3 E POWER \u2013 ARQUITETURAS POSS\u00cdVEIS<\/span><\/strong><\/p>\n

5.1 Redund\u00e2ncia<\/strong> <\/span><\/p>\n

Os sistemas Elipse E3 e Elipse Power SCADA possuem seus pr\u00f3prios gerenciamentos de redund\u00e2ncia. Para utiliz\u00e1-los, ser\u00e3o necess\u00e1rias duas chaves de produto em cada Servidor, cada uma delas configurada como uma VM diferente. Ent\u00e3o, nas op\u00e7\u00f5es de configura\u00e7\u00e3o do Dom\u00ednio do E3, as configura\u00e7\u00f5es da VM ser\u00e3o definidas, bem como outros perfis de redund\u00e2ncia e op\u00e7\u00f5es de configura\u00e7\u00e3o. Normalmente, a \u00a0redund\u00e2ncia do dom\u00ednio nativo \u00e9 capaz de ser ativa (ou de se recuperar de um servidor com failover) entre 2 e 30 segundos em m\u00e9dia, dependendo do tamanho da aplica\u00e7\u00e3o e de sua configura\u00e7\u00e3o.<\/p>\n

No entanto, a HA e a FT oferecem op\u00e7\u00f5es de redund\u00e2ncia diferentes, que podem ser utilizadas independentemente da redund\u00e2ncia nativa do E3.<\/p>\n

A HA permite reiniciar uma \u00fanica VM no caso da detec\u00e7\u00e3o de falhas no hardware ou no sistema operacional, e n\u00e3o de falhas internas do software. Neste caso, voc\u00ea ter\u00e1 apenas uma chave de produto de E3 em uma \u00fanica VM, que \u00e9 destru\u00edda e reiniciada do in\u00edcio. Mesmo quando um\u00a0 host f\u00edsico cai, a HA pode reinicializar a VM em outro host em cerca de 30 a 60 segundos em m\u00e9dia.<\/p>\n

A HA tamb\u00e9m pode ser utilizada juntamente com a redund\u00e2ncia nativa do E3, o que faz deste um esquema de quad-redund\u00e2ncia:<\/p>\n

\"\"
\nFigura 5 – High Availability<\/p>\n

Alguns hipervisores podem tamb\u00e9m carregar a HA separadamente, dependendo do n\u00famero de CPUs virtuais (vCPUs) na VM.<\/p>\n

J\u00e1 a FT, por sua vez, basicamente evita o tempo de startup HA\/VM a custo de rede e CPU, deixando a segunda VM\u00a0bloqueada com uma VM prim\u00e1ria. Em outras palavras, a FT \u00e9 capaz de substituir o sistema de redund\u00e2ncia nativo do E3, embora tenha sido desenvolvida para superar apenas falhas no hardware, assim como a HA.\u00a0 De qualquer modo, a FT ainda pode ser utilizada em conjunto com a redund\u00e2ncia nativa do E3 a fim de prevenir falhas tanto a n\u00edvel de hardware, SO, e software de aplica\u00e7\u00e3o.<\/p>\n

\"\"
\nFigura 6 – Fault Tolerance<\/p>\n

No entanto, em caso de falhas apenas no hardware, esta arquitetura pode nunca fazer um switchover para o\u00a0 E3 Server VM2 Stby utilizando redund\u00e2ncia nativa, porque a detec\u00e7\u00e3o de FT provavelmente acontecer\u00e1 primeiro.<\/p>\n

5.2\u00a0Arquivos e Bibliotecas do Projeto<\/strong> <\/span><\/p>\n

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\u00e2ncia nativa esteja sendo utilizada (ou seja, em ambas as VMs). Para que o E3 Studio configure uma aplica\u00e7\u00e3o sendo executada, ele deve ter\u00a0 acesso de rede aos servidores e aos arquivos de banco de dados, que podem ser declarados no Dom\u00ednio E3\u00a0 atrav\u00e9s de um atalho de rede (ex: \\\\MACHINE1\\Application<\/a>) ou de um atalho compartilhado de rede (como um diret\u00f3rio F:\\ ou G:\\, por exemplo).<\/p>\n

No entanto, tanto um hipervisor quanto uma ferramenta do Windows Server chamada DFS (Distributed File System) podem ser utilizados para simplificar a sincroniza\u00e7\u00e3o 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\u00e9m em outras m\u00e1quinas, como o E3 Studio. Embora para cada m\u00e1quina os atalhos pare\u00e7am 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\u00e7as quando estas acontecem.<\/p>\n

\u00a0\"\"
\nFigura 7 – Sistemas de Arquivos Distribu\u00eddos<\/p>\n

A fim de permitir que a sincroniza\u00e7\u00e3o aconte\u00e7a enquanto os processos principais estejam sendo executados, o E3 vers\u00e3o 4.5 introduz um recurso especial chamado \u201cHands-Off Mode\u201d<\/a>, que permite munda\u00e7as em tempo de execu\u00e7\u00e3o em arquivos de projeto, que devem ser habilitados a ser usados com o DFS, se poss\u00edvel.<\/p>\n

5.3\u00a0Banco de Dados<\/strong><\/span><\/p>\n

A redund\u00e2ncia nativa do E3 \u00e9 capaz de sincronizar bancos de dados hist\u00f3ricos de dados de processo (SQL ou Oracle). Entretanto, isto n\u00e3o faz sentido em um ambiente virtualizado, j\u00e1 que arquivos de bancos de dados podem ser armazenados em discos externos, e n\u00e3o dentro de cada VM. Por isso, por motivos pr\u00e1ticos, a sincroniza\u00e7\u00e3o de banco de dados nativo deve ser desabilitada.<\/p>\n

A abordagem mais recomendada para uma Aplica\u00e7\u00e3o E3 virtualizada \u00e9 desenvolver uma VM independente para o mecanismo de software de banco de dados (a VM onde s\u00e3o instalados o SQL Server ou o software Oracle) e colocar os arquivos de dados do DB diretamente nos discos externos, onde a informa\u00e7\u00e3o estar\u00e1 mais segura gra\u00e7as ao esquema RAID.<\/p>\n

6.\u00a0ELIPSE PLANT MANAGER<\/strong><\/span><\/p>\n

A arquitetura recomendada para o Elipse Plant Manager (EPM) depende de um armazenamento seguro para os arquivos correntes e de backups definidos pelo usu\u00e1rio para arquivos mais antigo.\u00a0 Para uma melhor performance, siga estes procedimentos:<\/p>\n

a)\u00a0Defina uma VM para o sistema SQL Server, com a HA caso esteja dispon\u00edvel.
\nb)\u00a0Defina uma VM para o EPM Server, com HA\/FT caso estejam dispon\u00edveis.
\nc)\u00a0Durante a configura\u00e7\u00e3o do\u00a0 EPM Database, crie atalhos diferentes para os arquivos Database e Log, com cada atalho representando diferentes discos f\u00edsicos\/volumes. Isto aumenta a capacidade de E\/S do sistema.
\nd)\u00a0Instale o Interface Server nas origens de dados locais.<\/p>\n

7\u00a0REFER\u00caNCIAS<\/strong><\/span><\/p>\n

http:\/\/www.vmware.com\/virtualization\/virtualization-basics\/what-is-virtualization.html<\/a>
\nhttp:\/\/en.wikipedia.org\/wiki\/Hypervisor<\/a>
\nhttp:\/\/www.cio.com\/article\/732479\/<\/span><\/a>
\nhttp:\/\/cloudpatterns.org\/design_patterns\/hypervisor_clustering<\/a>
\nManual do Usu\u00e1rio do Elipse E3, vers\u00e3o 4.5
\nManual do Usu\u00e1rio do Elipse Plant Manager, vers\u00e3o 2.0<\/p>\n

Artigos Relacionados<\/h3>\n
\n