USANDO A VIRTUALIZAÇÃO COMO FERRAMENTA DE APOIO AO PLANO DE RECUPERAÇÃO DE DESASTRES. PROPOSTA DE INDICADORES PARA AVALIÇÃO DOS BENEFÍCIOS E PERDAS COM A UTILIZAÇÃO DESTA

FACULDADE DE TECNOLOGIA DE CARAPICUÍBA

Diego Santana Zuqueto

Vinicius Rusew Vieira da Silva

USANDO A VIRTUALIZAÇÃO COMO FERRAMENTA DE APOIO

AO PLANO DE RECUPERAÇÃO DE DESASTRES.

PROPOSTA DE INDICADORES PARA AVALIÇÃO DOS

BENEFÍCIOS E PERDAS COM A UTILIZAÇÃO DESTA TECNICA

Trabalho de Graduação

Carapicuíba - SP

2011




AO PLANO DE RECUPERAÇÃO DE DESASTRES. PROPOSTA

DE INDICADORES PARA AVALIÇÃO DOS BENEFÍCIOS E

PERDAS COM A UTILIZAÇÃO DESTA TECNICA

Trabalho apresentado como exigência para

obtenção do Título de Tecnólogo em Segurança

da Informação, da Faculdade de Tecnologia de

Carapicuíba.

Orientador: Prof. Me. Tung Chiun Wen

Carapicuíba - SP

2011

Ficha Catalográfica




AO PLANO DE RECUPERAÇÃO DE DESASTRES. PROPOSTA

DE INDICADORES PARA AVALIÇÃO DOS BENEFÍCIOS E

PERDAS COM A UTILIZAÇÃO DESTA TECNICA

Essa pesquisa foi julgada e aprovada para a obtenção do Título de

Tecnólogo em Análise de Sistemas e Tecnologia da Informação, da

Faculdade de Tecnologia de Carapicuíba.

Carapicuíba, 26 de julho de 2011.

Prof. Dr. Walter Aloisio Santana

Diretor da Fatec - Carapicuíba

Banca examinadora

_________________________

Prof. Me. Tung Chiun Wen

_________________________

Prof. Dr. Olimpio Murilo Capeli

_________________________

Profa. Patrícia Lima Rocha

i

Dedicatória

Aos nossos pais que nos educaram e

apoiaram em todos os momentos desde o

nascimento até o dia de hoje, aos mestres

e colegas de classe que cruzamos

durante a vida acadêmica e ao nosso

orientador Tung C Wen.

ii

Agradecimentos

Aos nossos pais que nos colocaram nesse mundo, deram amor,

carinho, puxaram nossas orelhas quando necessário e nos apoiaram em

nossas decisões.

Aos amigos que às vezes deixamos de lado para poder nos

dedicar aos estudos e que esperamos que agora possamos voltar à

amizade de outrora.

Aos amigos que formamos nesse período de formação acadêmica

que tanto nos ajudaram nas horas das provas, listas e trabalhos assim

como nos também os ajudamos.

Aos chefes e colegas de trabalho que fizeram vista grossa quando

íamos ao trabalho não para trabalhar, mas sim para estudar.

Aos professores da FATEC Carapicuiba que transmitiram o seu

conhecimento para nós.

Aos funcionários da FATEC Carapicuiba que sempre foram

solícitos com nossas requisições.

Ao nosso orientador Tung C Wen que nos orientou e ajudou

principalmente nestes dois últimos semestres.

E a atual namorada e futura esposa do Vinicius Rusew que mesmo

com ele ficando vários dias sem a ver, foi compreensiva em todos os

momentos e principalmente neste ultimo semestre.

iii

Resumo

Na última década o mundo vivenciou uma série de catástrofes naturais como

terremotos, tsunamis, tornados e também desastres provocados pela ação

intencional do homem como atentados terroristas e outros, o que ocasiona além de

um número considerável de vítimas, perdas irreparáveis para diversas empresas de

todos os portes. Ao mesmo tempo a dependência em recursos de tecnologia da

informação cresce fazendo com que qualquer interrupção que cause

indisponibilidade no acesso ou no fornecimento desses recursos seja de grande

relevância para a continuidade do negócio. O desenvolvimento de uma estratégia de

recuperação de desastres surge como uma necessidade neste cenário e a redução

do tempo de indisponibilidade e consequentemente o tempo de recuperação (RTO)

é um fator crucial para a continuidade do negócio.

Utilizar a virtualização como ferramenta de apoio ao plano de recuperação

de desastres (PRD) reduz consideravelmente o RTO em um ambiente de produção,

entretanto ela introduz uma camada de abstração entre o sistema operacional, os

aplicativos e o hardware o que pode acarretar em diminuição ou não do

desempenho. Esta possível redução foi avaliada através de indicadores chave de

performance (KPI – Key Performance Indicators) com o intuito de mostrar não

somente os ganhos obtidos com a diminuição do RTO, mas também qual o impacto

causado no desempenho após a adição da camada de abstração caso ele ocorra e

seja relevante.

Palavras-chave: virtualização, plano de recuperação de desastres, tempo de

recuperação, indicadores, KPI.

iv

Lista de Tabelas

Tabela 1 - Dados WPM e RTO: Máquina Física ....................................................... 72

Tabela 2 - Dados WPM e RTO: Citrix Xen Server ..................................................... 73

Tabela 3 - Dados WPM e RTO: Microsoft Hyper-V ................................................... 73

Tabela 4 - Dados WPM e RTO: Oracle Virtual Box ................................................... 74

Tabela 5 - Dados WPM e RTO: VMware Server ....................................................... 74

v

Lista de Gráficos

Gráfico 1 - Previsões para gastos globais com TI (GARTNER,2011, traduzido) ......... 2

Gráfico 2 - Fatores que impulsionam a virtualização(Bowker & Laliberte 2008,

traduzido) .................................................................................................................. 44

Gráfico 3 - RTO ......................................................................................................... 75

Gráfico 4 – Indicador (objeto) disco: Average Disk Bytes/Read ................................ 76

Gráfico 5 - Indicador (objeto) disco: Average Disk Bytes/Write ................................. 76

Gráfico 6 - Indicador (objeto) disco: Current Disk Queue Length .............................. 77

Gráfico 7 - Indicador (objeto) disco: % Idle Time ....................................................... 77

Gráfico 8 - Indicador (objeto) memória: Avaliable MBytes ........................................ 79

Gráfico 9 - Indicador (objeto) memória: Commited Bytes .......................................... 79

Gráfico 10 - Indicador (objeto) memória: Page Faults / Sec ...................................... 80

Gráfico 11 - Indicador (objeto) processador: % Processor Time ............................... 81

Gráfico 12 - Indicador (objeto) processador: % User Time ....................................... 81

Gráfico 13 - Indicador (objeto) MS Excahnge IS: RPC Averaged Latency ................ 82

Gráfico 14 - Indicador (objeto) MS Exchange IS: RPC Requests .............................. 83

Gráfico 15 - Indicador (objeto) MS Exchange IS Mailbox: Local Delivery Rate ......... 84

vi

Lista de Figuras

Figura 1 - Relação quadrantes mágicos para virtualização x86 (BITTMAN et al.,

2010; WEISS et al., 2011 traduzido e modificado) ...................................................... 3

Figura 2 - Etapas do PCN (SNEDAKER 2007, traduzido) ........................................... 6

Figura 3 - O processo de gestão de riscos (ISO 27005) ............................................. 7

Figura 4 - Plano de continuidade e plano de recuperação, implementação e ciclo de

revisão da gestão de riscos. (SNEDAKER, 2007, traduzido) .................................... 11

Figura 5 - Tempos críticos de recuperação (SNEDAKER, 2007; traduzido) ............. 17

Figura 6 - O que é a virtualização (VERAS, 2011) .................................................... 18

Figura 7 - Arquitetura de virtualização (VERAS, 2011) ............................................. 19

Figura 8 - Máquina Virtual (VMware, 2007, traduzido) .............................................. 21

Figura 9 - Diagrama de uma máquina virtual (LAUREANO, 2006) ........................... 22

Figura 10 - Sistema de computador (LAUREANO, 2006) ......................................... 23

Figura 11 - Alguns sistemas existentes (LAUREANO, 2006, modificado) ................. 23

Figura 12 - Incompatibilidade entre plataformas (LAUREANO, 2006, modificado) ... 23

Figura 13 - Camada de compatibilidade(LAUREANO, 2006) .................................... 24

Figura 14 - Virtualização com hypervisor (VERAS, 2011) ......................................... 25

Figura 15 - Máquina virtual de tipo I (LAUREANO, 2006) ......................................... 26

Figura 16 - Arquitetura monolítica versus microkernelizada (VERAS, 2011) ............ 27

Figura 17 - Máquina virtual de tipo II (LAUREANO, 2006) ........................................ 28

Figura 18 - Abordagem híbrida para o tipo I (LAUREANO, 2006) ............................. 28

Figura 19 - Abordagem híbrida para o tipo II (LAUREANO, 2006) ............................ 29

Figura 20 - Virtualização de hardware (LAUREANO, 2006) ...................................... 30

Figura 21 - Virtualização de sistema operacional (LAUREANO, 2006) ..................... 30

Figura 22 - Virtualização de linguagens de programação (LAUREANO, 2006) ........ 31

Figura 23 - Níveis de privilégio sem virtualização na arquitetura x86 (VMware,2007,

modificado) ................................................................................................................ 32

Figura 24 - Estrutura de um processador x86 (LAUREANO, 2006) .......................... 32

Figura 25 - A abordagem de translação binária para a virtualização x86 (VMware,

2007) ......................................................................................................................... 33

Figura 26 - Representação da virtualização total (LAUREANO, 2006) ..................... 34

vii

Figura 27 - A abordagem de paravirtualização para a virtualização x86 (VMware,

2007) ......................................................................................................................... 35

Figura 28 - Representação da paravirtualização (LAUREANO, 2006) ...................... 36

Figura 29 - Alocação de memória para sistema convidado (LAUREANO , 2006) ..... 36

Figura 30 - Estrutura do funcionamento da máquina virtual em um processador x86

(LAUREANO, 2006) .................................................................................................. 37

Figura 31 - A abordagem assistida por hardware para a virtualização x86 ............... 38

Figura 32 - Diferença entre abstração e virtualização (LAUREANO, 2006) .............. 43

Figura 33 - Quadrante mágico para virtualização x86 (WEISS et al., 2011) ............. 45

Figura 34 - Pré-requisitos Exchange Server 2007 ..................................................... 48

Figura 35 - Windows Server 2008 Datacenter Edition(“Microsoft Corporation”) ........ 48

Figura 36 - Microsoft integração entre ferramentas (“Integração Microsoft Active

Directory”) .................................................................................................................. 49

Figura 37 - Windows Performance Monitor ............................................................... 63

Figura 38 - Tela de configuração da duração do teste no Microsoft Exchange Server

Load Generator ......................................................................................................... 64

Figura 39 - Grupo de clientes .................................................................................... 65

Figura 40 - Resumo da configuração do MELG ........................................................ 65

Figura 41 – Saída do MELG ...................................................................................... 66

Figura 42 - MELG: falha na execução ....................................................................... 71

viii

Lista de Abreviaturas, Siglas e Símbolos

Abreviaturas e Siglas /s = Por segundo.

2D = Duas Dimensões.

3D = Três Dimensões.

ABNT = Associação Brasileira de Normas Técnicas.

ADDS = Active Directory Domain Services (Serviço de Domínio de Diretório

Ativo).

AIN = Análise do Impacto nos Negócios.

AMD = Advanced Micro Devices.

API = Application Programming Interface (Interface de Programação de

Aplicação).

AS = Application Server (Servidor de Aplicação).

CEO = Chief Executive Office (Diretor Executivo).

CSV = Comma Separated Values.

CTSS = Compatible Time Sharing System (Sistema de Compartilhamento de

Tempo Compatível).

DDR = Double Data Rate.

DNS = Domain Name System (Serviço de Nomes de Domínio).

Dr. = Doutor.

E/S = Entrada/Saída.

ESG = Enterprise Strategy Group.

FQND = Fully Qualified Domain Name (Nome de Domínio Totalmente

Qualificado).

GHz = Gigahertz.

IBM = International Business Machine.

IDC = International Data Corporation.

IEC = International Electrotechnical Commission (Comissão Eletrotécnica

Internacional).

IIS = Internet Information Service (Serviço de Informação de Internet).

IPv4 = Internet Protocol Version 4 (Protocolo de Internet Versão 4).

ix

ISA = Instruction Set Architecture (Arquitetura de Conjunto de Instruções).

ISO = International Organizational for Standartization (Organização

Internacional para Padronização).

JVM = Java Virtual Machine (Máquina Virtual Java).

KB = Kilobyte.

KPI = Key Performance Indicator (Indicador chave de performance).

KVM = Kernel Based Virtual Machine (Máquina Virtual Baseada no Kernel).

MB = Megabyte.

Mbps = Megabits per Second (Megabits por segundo).

Me = Mestre.

MELG = Microsoft Exchange Server Load Generator.

MHz = Megahertz.

MIT = Massachussets Institute of Technology (Instituto de Tecnologia de

Massachessets).

MMC = Microsoft Management Console (Console de Gerenciamento Microsoft).

MMV = Monitor de Máquina Virtual.

ms = milissegundo.

MTD = Maximum Tolerable Downtime (Tempo Máximo de Indisponibilidade).

MV = Máquina Virtual.

NTFS = New Technology File System.

OWA = Outlook Web Access.

PC = Personal Computer.

PCN = Plano de Continuidade de Negócios.

PRD = Plano de Recuperação de Desastres.

Prof. = Professor.

RPC = Remote Procedure Call (Chamada de Procedimento Remoto).

RPM = Rotations per Minute (Rotações por Minuto).

RPO = Recovery Point Objective (Ponto de Recuperação Objetivo).

RTO = Recovery Time Objective (Tempo de Recuperação Objetivo).

SGBD = Sistema de Gerenciamento de Banco de Dados.

SO = Sistema Operacional.

SP = Service Pack.

TB = Terabyte.

TCO = Total Cost of Ownership (Custo Total de Propriedade).

x

TI = Tecnologia da Informação.

un = unidade.

UPS = Uninterruptible Power Supply (Sistema de Alimentação Ininterrupta).

WPM = Windows Performance Monitor [perfmon.exe](Monitor de Performance

do Windows).

WRT = Work Recovery Time (Tempo de Recuperação de Trabalho).

xi

Símbolos

© = Copyright

® = Marca registrada

1:1 = Um pra um

1:N = Um pra vários

N:1 = Vários para um

N:N = Vários para vários

Sumário

Resumo ...................................................................................................................... iii

Lista de Tabelas ......................................................................................................... iv

Lista de Gráficos ......................................................................................................... v

Lista de Figuras .......................................................................................................... vi

Lista de Abreviaturas, Siglas e Símbolos ................................................................. viii

Abreviaturas e Siglas ............................................................................................ viii

Símbolos ................................................................................................................. xi

INTRODUÇÃO ............................................................................................................ 2

CAPÍTULO 1 – FUNDAMENTAÇÃO TEÓRICA ................................................... 4

1.1. DEFINIÇÃO DO PLANO DE CONTINUIDADE DE NEGÓCIOS .................... 4

1.2. NECESSIDADE DE ELABORAÇÃO DE UM PLANO DE CONTINUIDADE

DE NEGÓCIO .......................................................................................................... 4

1.3. ETAPAS PARA ELABORAÇÃO DO PLANO ................................................. 5

1.4. GESTÃO DE RISCOS .................................................................................... 6

1.4.1. Risco ........................................................................................................ 7

1.4.2. Definição do Contexto ............................................................................. 8

1.4.3. Identificação dos Riscos .......................................................................... 8

1.4.4. Análise e Avaliação dos Riscos ............................................................... 8

1.4.5. Tratamento dos Riscos ............................................................................ 8

1.4.6. Monitoramento e Revisão ........................................................................ 9

1.5. ANÁLISE DO IMPACTO NOS NEGÓCIOS ................................................... 9

1.5.1. Elaboração da Análise de Impacto de Negócios ................................... 10

1.5.2. Impacto Operacional e Impacto Financeiro ........................................... 10

1.6. PLANO DE RECUPERAÇÃO DE DESASTRES .......................................... 10

1.6.1. Escopo de Um Plano de Recuperação de Desastres ............................ 11

1.6.2. Definição de Desastre ........................................................................... 12

1.6.3. Tipos de Desastres ................................................................................ 12

1.6.4. Equipes de Recuperação ...................................................................... 13

1.6.5. Sites Backup .......................................................................................... 15

1.6.6. Requisitos de Tempos de Recuperação ................................................ 15

1.7. VIRTUALIZAÇÃO ......................................................................................... 17

1.7.1. História da Virtualização ........................................................................ 19

1.7.2. Máquinas Virtuais .................................................................................. 20

1.7.3. Por Que Máquinas Virtuais? .................................................................. 22

1.7.4. Tipos de Máquinas Virtuais ................................................................... 24

1.7.5. Formas de Virtualização ........................................................................ 29

1.7.6. Técnicas de Virtualização ...................................................................... 31

1.7.7. Benefícios .............................................................................................. 39

1.7.8. Aplicações ............................................................................................. 40

1.7.9. Limitações ............................................................................................. 41

1.7.10. Emulação e Virtualização ...................................................................... 42

1.7.11. Abstração e Virtualização ...................................................................... 42

1.7.12. Ferramentas e Fornecedores ................................................................ 43

CAPÍTULO 2 – METODOLOGIA ............................................................................... 46

2.1 DEFINIÇÃO DO AMBIENTE ........................................................................ 46

2.1.1 Hardware Utilizado ................................................................................ 46

2.1.2 Servidor de E-mail ................................................................................. 46

2.1.3 Sistema Operacional ............................................................................. 48

2.1.4 Microsoft Exchange Server Load Generator .......................................... 50

2.1.5 Monitoramento de Desempenho ............................................................ 50

2.2 FERRAMENTAS DE VIRTUALIZAÇÃO UTILIZADAS ................................. 50

2.2.1 Citrix Xen Server .................................................................................... 50

2.2.2 Microsoft Hyper-V .................................................................................. 51

2.2.3 VMware ESXi ......................................................................................... 52

2.2.4 Oracle Virtual Box .................................................................................. 53

2.2.5 VMware Server ...................................................................................... 53

2.2.6 Microsoft Virtual PC ............................................................................... 54

2.3 INDICADORES ANALISADOS .................................................................... 54

2.3.1 Tempo de Recuperação ........................................................................ 54

2.3.2 Performance e Desempenho ................................................................. 55

2.4 LINHA DE TRABALHO ................................................................................ 56

2.4.1 Ambiente não-virtualizado ..................................................................... 56

2.4.2 Ambiente virtualizado ............................................................................ 57

2.4.3 Instalação do SO, atualizações (Windows Update) e configuração dos

serviços e pré-requisitos para o servidor de e-mail Exchange Server ............... 58

2.4.4 Instalação e configuração do servidor de email Exchange Server e

atualizações respectivas .................................................................................... 60

2.4.5 Execução dos testes de desempenho utilizando o Windows

Performance Monitor e Exchange Load Generator e coleta dos resultados

obtidos 62

2.4.6 Backup do Ambiente .............................................................................. 66

2.4.7 Crash do Ambiente e Verificação do Tempo de Recuperação (RTO) ... 68

CAPÍTULO 3 – DISCUSSÃO E RESULTADOS ........................................................ 70

3.1. DIFICULDADES E LIMITAÇÕES ENCONTRADAS ..................................... 70

3.1.1. VMWare ESXi ........................................................................................ 70

3.1.2. VMware Server ...................................................................................... 70

3.1.3. Microsoft Virtual PC ............................................................................... 70

3.1.4. Oracle Virtual Box .................................................................................. 71

3.1.5. Microsoft Hyper-V .................................................................................. 71

3.1.6. Citrix Xen Server .................................................................................... 72

3.2. DADOS COLETADOS ................................................................................. 72

3.3. DADOS COMPARATIVOS ENTRE OS AMBIENTES .................................. 74

3.3.1. Verificação do Tempo de Recuperação ................................................. 75

3.3.2. Disco (Físico e Lógico): ......................................................................... 75

3.3.3. Memória ................................................................................................. 78

3.3.4. Processador .......................................................................................... 80

3.3.5. MS Exchange IS .................................................................................... 82

3.3.6. MS Exchange IS Mailbox ....................................................................... 83

CONCLUSÃO ............................................................................................................ 85

TRABALHOS FUTUROS .......................................................................................... 87

REFERÊNCIAS BIBLIOGRÁFICAS .......................................................................... 88

2

INTRODUÇÃO

O trabalho tem como objetivo propor indicadores como tomada de decisão

para utilização da virtualização como ferramenta de apoio ao plano de recuperação

de desastres com o intuito de reduzir o tempo de indisponibilidade dos recursos de

tecnologia da informação (TI) e consequentemente o impacto financeiro causado

pela não disponibilidade dos mesmos. Através dos indicadores de desempenho foi

possível verificar não somente os benefícios obtidos com a utilização da

virtualização, mas também as consequências relacionadas a provável perda de

desempenho e avaliar se as tais inviabilizam ou não a utilização desta técnica. Para

isso inicialmente foi necessário obter informações em um contexto global das

previsões ou estimativas para o crescimento dos investimentos em TI, além de

apurar o crescimento das empresas de virtualização enfatizando as expectativas

para o aumento desta utilização.

De acordo com a (Gartner, 2011) os gastos corporativos com hardware,

software, serviços de TI e de telecomunicações no ano de 2010 ultrapassaram 3.401

bilhões de dólares e as previsões para 2011 indicam que o aumento em relação a

2010 será de 7,1% e que até 2015 os gastos se aproximem de 4.500 bilhões.

Gráfico 1 ‐ Previsões para gastos globais com TI (GARTNER,2011, traduzido)

3

Cada vez mais as empresas investem em recursos de tecnologia para

agregar serviços e prover melhoria de funções, e estes investimentos tendem a

aumentar nos próximos anos fazendo com que a dependência das empresas nestes

recursos aumente proporcionalmente.

Com relação à virtualização pode-se notar que um mercado que ainda tem a

VMware como líder passa a ser alvo de outras empresas que começam a ter melhor

posição e colocação o que indica constante investimento e procura de novas

soluções.

Figura 1 ‐ Relação quadrantes mágicos para virtualização x86 (BITTMAN et al., 2010; WEISS et al., 2011

traduzido e modificado)

Esta mudança de cenário evidência um aumento na demanda por soluções

virtualizadas e segundo (WEISS et al., 2011) a virtualização passa ser a base para

duas importantes tendências de mercado: a modernização da infraestrutura

melhorando a utilização e a velocidade para o provisionamento de recursos, e a

utilização da virtualização como base para computação em nuvem.

Com tais informações apuradas foi possível direcionar a elaboração deste

trabalho de forma permitir uma conclusão precisa e objetiva a respeito dos

conceitos, levantamentos e soluções abordadas.

4

CAPÍTULO 1 – FUNDAMENTAÇÃO TEÓRICA

1.1. DEFINIÇÃO DO PLANO DE CONTINUIDADE DE

NEGÓCIOS

O plano de continuidade de negócios ou PCN é uma metodologia que define

os processos para desenvolvimento e validação de um plano que tem por finalidade

a manutenção das operações necessárias ao negócio da empresa antes, durante e

após um desastre.

O objetivo do plano é diminuir o impacto e consequentemente a não

lucratividade causados por interrupções aos negócios, e está diretamente

relacionado com o gerenciamento dos elementos operacionais que viabilizam o bom

funcionamento do negócio. (SNEDAKER, 2007)

1.2. NECESSIDADE DE ELABORAÇÃO DE UM PLANO DE

CONTINUIDADE DE NEGÓCIO

Com a atual dependência das empresas em recursos de TI qualquer

interrupção no fornecimento ou acesso a estes recursos que possa afetar a

disponibilidade dos elementos operacionais é algo de grande relevância. Este fato

precisa ser analisado cuidadosamente pela alta cúpula das empresas

independentemente de seu porte.

Segundo (WALLACE; WEBBER, 2004) o responsável pelo plano deve possuir

influência organizacional necessária para dar credibilidade, conseguir recursos

financeiros, dirigir estrategicamente o plano e garantir a cooperação necessária de

todos os departamentos envolvidos. É evidente que este papel é de

responsabilidade do CEO da empresa ou do vice-presidente. Entretanto tal

necessidade é muitas vezes ignorada devido ao custo de implementação e

manutenção contínua do plano.

5

Para averiguar a preparação da empresa diante de uma situação de desastre

que venha ocasionar a interrupção das operações e consequentemente

indisponibilidade dos recursos de TI é necessário responder as seguintes questões

com ‘SIM’:

“1) Você sabe quanto tempo o sistema de alimentação ininterrupta (UPS) irá

alimentar os equipamentos se a rede elétrica falhar? Você sabe qual o equipamento

pode ser desligado primeiro?

2) Você sabe onde obter suprimentos críticos se o seu principal fornecedor

tiver um problema?

3) Você sabe a localização de todas as suas licenças de software?

4) Você tem um plano para manter contato com clientes para se certificar de

que não irão imediatamente para os concorrentes se ouvir que um desastre atingiu a

sua empresa?

5) Você testou os seus backups para saber se consegue restaurar dados

críticos? E aplicações personalizadas? O seu software de backup é atualizado?

6) Os seus funcionários sabem a quem chamar, se vêem a notícia de que há

um incêndio no prédio?

7) Você sabe o que fazer se uma retroescavadeira cortar os cabos de

telecomunicações?

8) As suas definições de vírus estão atualizadas?

9) Você pode dizer a localização das suas informações de garantia, códigos

de registro, e chaves para todo o hardware e software?

10) Você tem um plano de utilização de equipamentos alternativos até que

você possa restaurar ou substituir o equipamento de produção? "

1.3. ETAPAS PARA ELABORAÇÃO DO PLANO

Para (SNEDAKER, 2007) a elaboração do plano é constituída das seguintes

etapas:

Iniciação do projeto;

Avaliação/gestão de risco;

6

Análise de impacto de negócios;

Desenvolvimento da estratégia de mitigação/recuperação;

Desenvolvimento do plano;

Treinamento, teste e auditoria;

Manutenção do plano.

Figura 2 ‐ Etapas do PCN (SNEDAKER 2007, traduzido)

Neste trabalho as etapas de gestão de risco e análise de impacto de negócios

serão abordadas e também a parte procedimental do plano caracterizando o plano

de recuperação de desastres.

1.4. GESTÃO DE RISCOS

A gestão de riscos é parte de extrema importância para o desenvolvimento de

um PCN, nesta etapa define-se o processo de identificação e análise dos eventos

que possam resultar em recuperação.

A gestão de risco engloba o contexto avaliado, identificação dos riscos,

análise de riscos, avaliação de riscos e o tratamento ou aceitação dos riscos.

(COOPER et al., 2005)

7

Figura 3 ‐ O processo de gestão de riscos (ISO 27005)

1.4.1. Risco

O risco é a probabilidade de ocorrência ou concretização de uma ameaça

devido à existência de uma determinada vulnerabilidade dos ativos de TI, podendo

resultar em impacto nos negócios. (STONEBURNER et al., 2002)

8

1.4.2. Definição do Contexto

Nesta etapa é estabelecido o ambiente organizacional onde a avaliação de

risco será feita além de especificar os objetivos pretendidos com a gestão de risco e

definir os elementos dos processos de identificação, e a avaliação dos riscos.

(COOPER et al., 2005)

1.4.3. Identificação dos Riscos

O processo de identificação dos riscos deve abranger todos os riscos que

podem impactar o negócio da organização, riscos não identificados não poderão ser

avaliados e acontecimentos não esperados podem ocorrer, causando

indisponibilidade operacional. (COOPER et al., 2005)

1.4.4. Análise e Avaliação dos Riscos

Segundo (COOPER et al., 2005) a análise dos riscos é desempenhada

através da utilização de informações disponíveis para encontrar a frequência da

ocorrência de eventos e a proporção das consequências destes eventos. Já a

avaliação de risco determina a significância do risco de acordo com critérios

estabelecidos.

O propósito desta etapa é a priorização dos riscos identificados.

1.4.5. Tratamento dos Riscos

Define o que será feito para mitigar os riscos identificados com o objetivo de

diminuir a exposição e o impacto nos negócios. Inicia-se com o tratamento dos

riscos que possuem maior probabilidade de ocorrência com o intuito de reduzir

(diminuir consequências negativas), reter (aceitação da perda associada ao risco),

evitar (não fazer parte da situação de risco) ou transferir o risco.

9

Após o tratamento dos riscos, caso ainda haja algum evento que possa

produzir risco (risco residual), o tratamento deverá ser realizado novamente.

(KLIPPER, 2011)

1.4.6. Monitoramento e Revisão

É necessário monitorar os riscos de forma a conseguir revisar os processos

de análise e avaliação, e identificar melhorias para o tratamento dos riscos.

(KLIPPER, 2011)

1.5. ANÁLISE DO IMPACTO NOS NEGÓCIOS

Com a gestão de riscos é possível gerenciar e desenvolver métodos para

avaliação e mitigação dos riscos, entretanto também há a etapa pós-identificação e

avaliação que consiste em analisar o impacto nos negócios. Durante a etapa de

avaliação dos riscos são análisados os eventos que podem ser ameaças para a

empresa, já a análise de impacto nos negócios tem como intuito identificar as

funções críticas do negócio e o impacto causado caso haja indisponibilidade dessas

funções.

É fundamental para a análise do impacto nos negócios (AIN) entender os

processos vitais para a operação da empresa e compreender o impacto que a

interrupção desses processos acarretaria ao negócio. (SNEDAKER, 2007)

(SNEDAKER, 2007) relata que a AIN tem como objetivo:

“Adquirir uma compreensão dos objetivos mais importantes da

organização, a prioridade de cada um, e os prazos para a retomada

desses objetivos após uma interrupção não programada;

Informar o tempo máximo de indisponibilidade de cada função;

Fornecer as informações de recurso de forma que uma estratégia de

recuperação apropriada seja determinada / recomendada;

10

Expor as dependências existentes internamente e externamente para

atingir objetivos críticos.”

1.5.1. Elaboração da Análise de Impacto de Negócios

A AIN pode ser elaborada a partir de 7 etapas (SNEDAKER, 2007):

Identificar os principais processos e funções ao negócio;

Estabelecer requisitos para a recuperação dos negócios;

Determinar interdependência entre os recursos;

Determinar o impacto nas operações;

Desenvolver prioridades e classificação dos processos de negócio e

funções;

Desenvolver requisitos de tempo de recuperação;

Determinar o impacto financeiro, operacional e legal das interrupções.

1.5.2. Impacto Operacional e Impacto Financeiro

Interrupções que causam perdas consideráveis são as que causam impactos

operacionais e financeiros. O impacto operacional endereça o impacto não

monetário ou como as pessoas, processos e a tecnologia serão afetados por uma

interrupção e qual a melhor maneira para abordar ou trabalhar este impacto. Já o

impacto financeiro abrange a perda monetária e como uma interrupção pode

prejudicar a renda da empresa. (SNEDAKER, 2007)

1.6. PLANO DE RECUPERAÇÃO DE DESASTRES

As etapas de gestão de risco e AIN possuem grande importância para

elaboração de um PCN, no entanto o plano envolve o estabelecimento dos

procedimentos e a execução das ações necessárias para recuperação. Esta etapa

do plano relacionada a parte procedimental caracteriza o plano de recuperação de

desastres (PRD).

11

O PRD é a parte do PCN que lida com o impacto imediato causado por um

evento ou desastre e tem a função de mitigar os efeitos de forma rápida. O PRD

basicamente define as ações a serem tomadas ou procedimentos a serem seguidos

para recuperação de um desastre. (WALLACE; WEBBER, 2004; SNEDAKER, 2007)

Durante o processo de recuperação há um momento em que o PRD é

sobreposto pelo PCN, pois tarefas como o estabelecimento de sistemas temporários

e implementações de segurança nas novas instalações estão relacionados com

ambos.

Figura 4 ‐ Plano de continuidade e plano de recuperação, implementação e ciclo de revisão da gestão de

riscos. (SNEDAKER, 2007, traduzido)

1.6.1. Escopo de Um Plano de Recuperação de Desastres

Com a elaboração de um PRD é possível melhorar a estratégia de

recuperação a qual deve possuir os seguintes itens como base:

Limitar a magnitude de qualquer perda, diminuindo o tempo de

interrupção de serviços e aplicativos críticos;

Avaliar o dano e reparar o dano;

Recuperar dados e informações necessárias para o funcionamento de

aplicações críticas;

Gerenciar a estratégia de recuperação de uma maneira efetiva e

organizada;

Prepara a equipe de tecnologia da Informação para responder de forma

eficiente em situações de recuperação de desastres.

12

A partir do desenvolvimento de um PRD viabiliza-se a restauração de

aplicações críticas, diminuindo o impacto causado devido à indisponibilidade de

recursos. (MARTIN, 2002)

1.6.2. Definição de Desastre

Segundo o dicionário Houaiss desastre significa “evento ou acontecimento

que causa sofrimento e grande prejuízo (físico, moral, material e/ou emocional),

desgraça, infortúnio”.

A concretização de ameaças e consequentemente o impacto causado

caracterizam um desastre ou interrupção de negócio dependendo de suas

proporções, o desastre é um evento que interrompe uma parte ou toda a operação

crítica ao negócio. (WALLACE; WEBBER, 2004).

1.6.3. Tipos de Desastres

De acordo com (SNEDAKER, 2007) existem 3 tipos de desastres à serem

considerados:

Naturais;

Ação humana;

Acidentais e tecnológicos.

1.6.3.1. Desastres Naturais

Ao se ouvir a palavra desastre é de comum pensar em terremotos, furacões,

erupções vulcânicas, enchentes e diversos outros acontecimentos ocasionados pela

força da natureza. Mesmo que muitos destes eventos possam ser previstos, muitas

vezes tais ocorrências podem devastar empresas dependendo de suas proporções.

13

Os desastres naturais contemplam:

Desastres relacionados ao frio (avalanche, nevasca, etc);

Desastres relacionados ao calor (tempestade, enchente, fogo, etc);

Desastres geológicos (terremoto, tsunami, erupção vulcânica, etc).

1.6.3.2. Desastres por Ação Humana

O desastre causado pelo homem intencionalmente é classificado como ação

humana:

Terrorismo (ataque armado, etc);

Bomba (ameaça de bomba, explosão);

Ataque cibernético (pequena intrusão, grande intrusão, etc);

Desordem civil, tumultos, distúrbios;

Protestos.

1.6.3.3. Desastres Acidentais ou Tecnológicos

Os desastres acidentais ou tecnológicos são causados pela ação do homem

com a exceção de não serem causados intencionalmente (SNEDAKER, 2007):

Falhas e acidentes de infraestrutura (eletricidade, gás, etc);

Infraestrutura do sistema de informação (queda, falha de sistema, etc);

Falha na rede elétrica ou subestação;

Incidente em instalação de energia nuclear.

1.6.4. Equipes de Recuperação

A definição das equipes e identificação de suas responsabilidades é de suma

importância para o bom funcionamento do plano. Saber quem faz o que, como e

quando faz, agiliza o processo de recuperação de desastre, além de economizar

esforços e minimizar prejuízos.

14

Totalizam-se 11 equipes com diferentes funções: (WEN, 2011)

Equipe de coordenadores: exerce o processo de coordenação do plano

de forma a garantir que a restauração do processamento ocorra sem

exceder o prazo estipulado, priorizando a função (criticidade) de cada

sistema.

Equipe gerencial: garante que os procedimentos para restauração do

processamento ocorram dentro do prazo acordado.

Equipe de salvamento: provê informações para a equipe gerencial para

que a mesma decida ativar ou não o plano e avaliar a extensão dos danos

causados pelo desastre.

Equipe de logística: provê os recursos de serviços administrativos e de

comunicações para as demais equipes.

Equipe de instalações físicas: assegura que as instalações onde o

processo de recuperação será executado estejam prontas para receber

pessoas e equipamentos.

Equipe de operação: possui como função, garantir que o processamento

normal possa ser iniciado tão logo os dados, os equipamentos e as

comunicações necessárias estejam disponíveis.

Equipe de hardware: disponibilizar os equipamentos de processamento

de dados quando requeridos.

Equipe de software: disponibilizar os softwares requeridos.

Equipe de telecomunicação: disponibilizar as linhas de comunicação e

os equipamentos relacionados.

Equipe de desenvolvimento: garantir que não haja perda de dados ou

informações durante a recuperação das aplicações necessárias e

principalmente das com alta criticidade.

Equipe de segurança: cria, mantém, divulga e coordena a ativação do

plano além de garantir que um nível mínimo de segurança seja mantido

durante o processo de restauração visando manter os níveis de serviços

acordados com os usuários.

15

1.6.5. Sites Backup

Dentre os tipos de sites de backup existentes, o que os diferencia além do

tempo para recuperação é também a confiabilidade e o custo envolvido.

Os sites backup existentes são:

Hot backup: este modelo de site caracteriza o completo espelhamento da

infraestrutura de um site, tornando-o capaz de assumir as operações no

momento exato da detecção de falha do site principal. Este é também o

que provê recuperação em um menor período de tempo. (KAHANE et al.,

1988; TRINDADE, 2008)

Warm backup: contém a infraestrutura necessária para operação, porém

não totalmente preparada. Neste caso o período de recuperação é maior

do que o do hot backup. (KAHANE et al., 1988; TRINDADE, 2008)

Split site: contempla dois sites, porém com abrangência menor do que o

hot backup. O segundo site neste caso pode manter as operações

cruciais para o desenvolvimento do negócio. (KAHANE et al., 1988)

Cold backup: suporta mínimos recursos de TI, porém tem pouca

infraestrutura preparada para a operação. (TRINDADE, 2008)

Mutual backup: site de backup compartilhado por duas organizações

diferentes que possuem um acordo de compartilhamento. É a solução

mais barata de site de backup, porém também é a menos eficiente.

(KAHANE et al., 1988)

1.6.6. Requisitos de Tempos de Recuperação

Os requisitos de tempo de recuperação estão relacionados com a duração do

impacto causado, ou seja, quanto tempo levará para restaurar as operações.

Segundo (SNEDAKER, 2007) existem 4 requisitos:

Maximum Tolerable Downtime (MTD): é o período de tempo máximo

que o negócio pode suportar com a ausência ou indisponibilidade de uma

determinada função de negócio necessária ao desenvolvimento das

16

operações. Cada função de negócio terá MTDs diferentes de acordo com

sua criticidade. O tempo de indisponibilidade é composto por dois

elementos onde MTD = RTO + WRT.

Recovery Time Objective (RTO): é o tempo disponível para recuperação

dos sistemas e recursos interrompidos pelo desastre, é basicamente o

tempo para realizar a reinstalação dos sistemas e deixá-los funcionais,

por exemplo, caso o MTD seja de três dias o RTO deverá ser realizado

em um dia, pois os demais dias serão utilizados para o WRT.

Work Recovery Time (WRT): é o tempo para que as funções críticas ao

negócio voltem a normal operação uma vez que os sistemas (hardware,

software e configurações necessárias) são restaurados. Esta área é

muitas vezes esquecida, pois se os sistemas estão funcionando eles

estão prontos para utilização de uma perspectiva do departamento de TI,

porém em uma perspectiva de função de negócio existem outras etapas

que precisam ser executadas antes de retornar a normal operação e o

tempo para essa etapa precisa estar dentro do MTD.

Recovery Point Objective (RPO): é a quantidade ou extensão de dados

perdidos que podem ser tolerados pelos sistemas críticos que compõem o

negócio.

A Figura 5 exemplifica a função de cada requisito de recuperação:

17

Figura 5 ‐ Tempos críticos de recuperação (SNEDAKER, 2007; traduzido)

Ponto 1 – RPO: quantidade máxima de perda de dados baseado em rotinas

de backup e necessidade de dados.

Ponto 2 – RTO: o tempo necessário para restaurar os sistemas críticos.

Ponto 3 – WRT: o tempo gasto para recuperar os dados perdidos (baseado

no RPO) e adicionar os dados do trabalho acumulado (dados gerados

manualmente durante a interrupção do sistema).

Ponto 2 e 3 – MTD: a duração do RTO mais o WRT.

Ponto 4: testar, verificar, e retornar as operações normais.

1.7. VIRTUALIZAÇÃO

Para (VERAS, 2011) a virtualização pode ser conceituada de duas maneiras:

Particionamento de servidores físicos em servidores lógicos, tornando-se

um aliado para consolidação de servidores;

18

Figura 6 ‐ O que é a virtualização (VERAS, 2011)

Uma camada de abstração entre o hardware e o software protegendo o

acesso direto aos recursos físicos do hardware permitindo que as

aplicações e os sistemas operacionais sejam isolados da camada de

hardware.

Já (SING, 2004) caracteriza a virtualização como uma forma de dividir os

recursos de um computador em vários ambientes de execução, aplicando-se um ou

mais conceitos de patrulhamento de hardware e/ou software, compartilhamento de

tempo, simulação parcial ou completa da máquina, emulação entre outros.

Para (LAUREANO, 2006) a virtualização é a interposição do software

(máquina virtual) em várias camadas do sistema.

19

Figura 7 ‐ Arquitetura de virtualização (VERAS, 2011)

1.7.1. História da Virtualização

Com a publicação do artigo Time Sharing Processing in Large Fast

Computers desenvolvido por Christopher Strachey (cientista em computação) e

elaborado para a conferência internacional de processamento da informação em

Nova York no ano de 1959, Christopher aplicou um novo conceito para máquinas de

grande porte (mainframe) utilizando multiprogramação em tempo compartilhado, e

fez com que as máquinas pudessem ter melhor aproveitamento de recursos de

hardware.

O MIT baseou-se no trabalho desenvolvido por Strachey e elaborou o padrão

CTSS (Compatible Time Sharing System). Com base na evolução do padrão a IBM

adentrou o multiprocessamento nos mainframes permitindo que várias unidades de

processamento trabalhassem como uma só. Depois de algum tempo surgiram as

primeiras formas de virtualização, pois os mainframes utilizavam o conceito de

memória virtual já como recurso do sistema operacional e com este recurso foi

possível realizar a abstração e o mapeamento da memória real para memória virtual.

20

As primeiras máquinas virtuais desenvolvidas foram as máquinas virtuais de

processo que emulavam o comportamento de um sistema A em um sistema B,

entretanto está técnica possuía como desvantagem o desempenho pois era

necessário emular todas as instruções do processador e também o desperdício da

capacidade do hardware. Com o intuito de melhorar o desempenho das máquinas

virtuais de processo os MMVs (monitores de máquinas virtuais) foram desenvolvidos

para atuar como uma camada de software entre o hardware e o sistema operacional.

A grande vantagem dos MMVs era que possuíam melhor eficiência para o

tratamento de dispositivos de E/S.

.

Com o passar dos anos e o aumento do poder de processamento dos

servidores baseados na arquitetura x86, a virtualização se tornou um aliado para

redução do TCO dos datacenters e para consolidação de servidores. Entretanto

existia um problema para implementação da virtualização em servidores da

arquitetura x86 que foi solucionado no final da década de 90 com o surgimento da

VMware em 1998, criada por Diana Greene e Mendel Rosenblun permitindo a

virtualização para plataforma x86.

A virtualização atendeu uma antiga demanda da área de TI ocasionada pelo

mau uso de servidores x86, onde havia apenas uma única aplicação executando

que utilizava um mínimo de recursos e para efeitos de segurança e disponibilidade

não podia executar com outros aplicativos em um mesmo servidor físico sem uma

camada que isolasse a aplicação do hardware.

Atualmente com o crescimento de empresas de virtualização em especial a

VMware, fizeram com que a virtualização se tornasse uma revolução na área de TI e

pesquisas do IDC indicam que haverá maior investimento nesta área no ano de

2011 em relação aos anos anteriores.(VERAS, 2011)

1.7.2. Máquinas Virtuais

Uma máquina real é composta por diversos componentes físicos que

permitem ao sistema operacional e as aplicações efetuarem diversas operações.

Analisando uma máquina real, o processador e o chipset da placa-mãe fornecem os

21

elementos necessários para realizar o processamento dos dados, alocação de

memória e controle de dispositivos de E/S, e as operações de baixo nível são

executadas através de drivers instalados no sistema operacional para acessar as

funções dos dispositivos de hardware. (LAUREANO, 2006)

Já nas máquinas virtuais (Figura 8) os recursos de processamento, memórias

e outros são virtualizados. (VERAS, 2011)

Figura 8 ‐ Máquina Virtual (VMware, 2007, traduzido)

Uma máquina virtual é uma cópia de um sistema físico que é isolada e

totalmente protegida. (LAUREANO, 2006)

Para (VERAS, 2011) é um container de software (Figura 9) completamente

isolado e com capacidade para executar sistemas operacionais e aplicações como

se fosse um servidor físico.

22

Figura 9 ‐ Diagrama de uma máquina virtual (LAUREANO, 2006)

A diferença entre máquinas físicas e máquinas virtuais não é identificada por

um sistema operacional, aplicações e demais computadores em rede.

1.7.3. Por Que Máquinas Virtuais?

Nos sistemas computacionais existem basicamente três componentes:

Hardware;

Sistema Operacional ou SO;

Aplicações.

23

Figura 10 ‐ Sistema de computador (LAUREANO, 2006)

O SO recebe solicitações das aplicações e controla o acesso aos recursos de

hardware, este por sua vez tem a finalidade de executar as operações solicitadas

pelas aplicações. Os SOs, as aplicações e também o hardware com o decorrer dos

anos foram projetados em plataformas diferentes e normalmente incompatíveis.

Figura 11 ‐ Alguns sistemas existentes (LAUREANO, 2006, modificado)

Como resultado as aplicações desenvolvidas para uma plataforma específica

não poderiam ser executadas em outras plataformas. (LAUREANO, 2006)

Figura 12 ‐ Incompatibilidade entre plataformas (LAUREANO, 2006, modificado)

As máquinas virtuais criam uma camada (virtualização) para tornar

compatíveis plataformas operacionais diferentes e oferecem ambientes de execução

24

completos. Deste modo, uma plataforma pode executar SOs diferentes

simultaneamente.(LAUREANO, 2006).

Figura 13 ‐ Camada de compatibilidade(LAUREANO, 2006)

1.7.4. Tipos de Máquinas Virtuais

Uma máquina virtual é um ambiente criado por um monitor de máquina virtual,

MMV ou hypervisor.(LAUREANO, 2006)

Segundo (VERAS, 2011) o hypervisor é a plataforma de máquina virtual, ou

uma camada de virtualização que entrega instruções para o SO convidado

equivalentes a um processador físico e tem como função o agendamento, gerência

da memória, permite a criação de partições (isolamento) e faz manutenção do

estado da máquina virtual. Funciona como uma camada de software que permite

que vários SOs diferentes sejam executados de maneira isolada em um único

hardware.

25

Figura 14 ‐ Virtualização com hypervisor (VERAS, 2011)

Aspectos como o desempenho e escalabilidade do hypervisor caracterizam o

bom funcionamento da virtualização, a segurança dos sistemas virtualizados e a

facilidade para alterar recursos computacionais sem interrupções aos sistemas são

itens de grande importância e necessários a um hypervisor. (VERAS, 2011)

Para (LAUREANO, 2006) há duas abordagens diferentes para se construir

máquinas virtuais, as do tipo I e II:

Tipo I: sistema em que o hypervisor é implementado entre o hardware e o

sistema convidado (guest system).

Tipo II: o hypervisor é implementado como um processo de um SO real

subjacente.

Para maximizar o desempenho o hypervisor sempre que possível permite que

a máquina virtual execute diretamente sobre o hardware em modo usuário, e retoma

sempre que a maquina virtual tenta executar uma operação que possa afetar o

correto funcionamento do sistema ou o conjunto de operações de outras máquinas

virtuais ou do próprio hardware.

26

1.7.4.1. Tipo I

Neste tipo o hypervisor é executado diretamente no hardware do computador

e também é conhecido como baremetal. A função de um hypervisor do tipo I é

basicamente o compartilhamento de recursos de hardware (processador, memória,

meios de armazenamento e dispositivos de E/S) entre as máquinas virtuais, fazendo

com que cada máquina virtual tenha a ilusão de que os recursos são únicos e

exclusivos a ela. (VERAS, 2011)

De acordo com (LAUREANO, 2006) nas máquinas do tipo I (Figura 15) o

hypervisor tem o controle do hardware e cria um ambiente de máquinas virtuais,

onde cada máquina virtual se comporta como uma máquina física completa podendo

executar o seu próprio SO.

Figura 15 ‐ Máquina virtual de tipo I (LAUREANO, 2006)

Exemplos: VMware ESX, Citrix Xen Server, Microsoft Hyper-V.

Para (VERAS, 2011) no contexto de hypervisor do tipo I existem duas

características a serem consideradas:

Hypervisor monolítico;

Hypervisor microkernelizado.

Os hypervisores monolíticos emulam o hardware totalmente para as

máquinas virtuais e os drivers são instalados no hypervisor, já nos microkernelizados

os drivers são instalados na própria máquina virtual (Figura 16).

27

Figura 16 ‐ Arquitetura monolítica versus microkernelizada (VERAS, 2011)

1.7.4.2. Tipo II

Segundo (VERAS, 2011) o tipo II de máquina virtual (Figura 17) é uma

aplicação responsável por prover o fornecimento de um ambiente computacional de

execução para outras aplicações. Um SO convidado e um hardware virtualizado são

criados na camada de virtualização e executados sobre os recursos de hardware do

SO nativo (SO hospedeiro ou host system).

Nas maquinas virtuais do tipo II, o hypervisor é executado sobre um sistema

anfitrião ou hospedeiro como um processo num sistema real, funcionado de forma

análoga ao tipo I e tendo como maior diferença a existência de um sistema abaixo

deste onde o hypervisor simula todas as operações do sistema anfitrião.

(LAUREANO, 2006)

28

Figura 17 ‐ Máquina virtual de tipo II (LAUREANO, 2006)

Exemplos: VMware® Server, Oracle Virtual Box e Microsoft Virtual PC.

1.7.4.3. Máquinas Virtuais com Abordagens Híbridas A arquitetura híbrida reúne as qualidades das maquinas virtuais de tipo I e II,

podendo-se agregar características das de tipo I na II ou vice-versa. Na pratica,

várias otimizações são aplicadas com o intuito de melhorar o desempenho das

aplicações nos sistemas convidados. (LAUREANO, 2006)

Otimização usual para o tipo I:

Figura 18 ‐ Abordagem híbrida para o tipo I (LAUREANO, 2006)

1 - Sistema convidado acessa diretamente o hardware.

Otimizações usuais para o tipo II são:

29

Figura 19 ‐ Abordagem híbrida para o tipo II (LAUREANO, 2006)

1 - Sistema convidado acessa diretamente o sistema anfitrião;

2 - Sistema convidado acessa diretamente o hardware;

3 - Hypervisor acessa diretamente o hardware.

1.7.5. Formas de Virtualização

A virtualização é a interposição do software (máquina virtual) em várias

camadas do sistema, uma forma de dividir os recursos de um computador em vários

ambientes de execução.

Segundo (ROSENBLUM, 2004) e (NANDA; CHIUEH, 2005) as formas de

virtualização são:

Virtualização do hardware: a virtualização exporta o sistema real

como abstrato, semelhante ao original. Neste tipo de virtualização qualquer software

escrito na arquitetura nativa irá funcionar no sistema convidado (Figura 20).

30

Figura 20 ‐ Virtualização de hardware (LAUREANO, 2006)

Virtualização de sistema operacional: onde a virtualização exporta

um sistema operacional como abstrato e a máquina virtual executa as aplicações ou

um conjunto delas de um sistema operacional específico (Figura 21).

Figura 21 ‐ Virtualização de sistema operacional (LAUREANO, 2006)

Virtualização de linguagens de programação: a virtualização cria

uma aplicação no topo do sistema onde as linguagens serão executadas, por

exemplo, a máquina virtual Java (Figura 22)

31

Figura 22 ‐ Virtualização de linguagens de programação (LAUREANO, 2006)

Abstração da Instruction Set Architecture (ISA): onde a

virtualização é implementada com o uso da emulação completa da ISA, neste caso o

emulador trata as instruções do sistema convidado e as executa utilizando as

instruções do sistema nativo.

Abstração da camada de hardware: onde o hypervisor simula a

arquitetura completa para o sistema virtualizado.

Nível de sistema operacional: a virtualização é implementada através

de chamadas de sistemas especificas, criando uma camada para isolamento de

processos.

Nível de aplicação: a virtualização cria uma camada de abstração por

meio de uma camada de execução onde as aplicações a utilizam para executar as

informações do programa.

Bibliotecas de interface para o usuário: a virtualização neste nível

ocorre no topo do SO, onde vários sistemas e aplicações são escritos utilizando um

conjunto de APIs e exportados para o nível do usuário por meio de bibliotecas.

1.7.6. Técnicas de Virtualização

Os processadores da arquitetura x86 trabalham com 4 níveis de privilégios ou

Rings (0, 1, 2 e 3), sendo que cada nível caracteriza o privilégio de execução de

códigos binários dentro do processador (Figura 23). As aplicações em nível de

usuário são executadas no Ring 3, já o SO por necessitar acesso direto ao hardware

e memória é executado no Ring.0. (LAUREANO, 2006; VMware, 2007)

32

Figura 23 ‐ Níveis de privilégio sem virtualização na arquitetura x86 (VMware,2007, modificado)

Na prática somente os níveis 0 e 3 são utilizados, como descrito na Figura 24:

Figura 24 ‐ Estrutura de um processador x86 (LAUREANO, 2006)

Para conseguir criar a camada de virtualização foi necessário colocá-la abaixo

do nível de operação e de privilégio do SO (Ring 0), dessa forma o SO continuaria

tendo maior privilégio do que as aplicações executadas no Ring 3, porém menos

privilégio do que o hypervisor. Além disso, algumas instruções não podem ser

virtualizadas pelo fato de possuírem diferentes significados (semântica de

instruções) quando executadas em um modo não privilegiado. Para viabilizar criação

e gerenciamento de máquinas virtuais existem 4 técnicas que podem ser

empregadas:

33

Virtualização total;

Paravirtualização;

Virtualização assistida por hardware;

Recompilação dinâmica.

1.7.6.1. Virtualização Total

A virtualização total ocorre através da combinação dos recursos de translação

binária e execução direta (Figura 25), viabilizando a tradução do código do kernel

que substitui as instruções não virtualizadas com novas sequencias de instruções

que terão o efeito desejado no hardware virtual. (VMware, 2007)

Figura 25 ‐ A abordagem de translação binária para a virtualização x86 (VMware, 2007)

O termo virtualização total é utilizado porque o SO convidado é

completamente abstraído ou dissociado do hardware subjacente pela camada de

virtualização fazendo com que o mesmo não saiba que está sofrendo o processo de

virtualização. Uma grande vantagem desta técnica é a criação de uma réplica do

hardware permitindo que o SO e as aplicações sejam executados da mesma forma

que no hardware original, eliminando assim a necessidade de modificação do SO

para implementação desta técnica. (VMware, 2007)

34

Para (VERAS, 2011) esta técnica implementa total abstração do sistema

físico e facilita a migração de máquinas virtuais entre servidores, além disso provê

maior segurança com o isolamento entre as máquinas virtuais, porém pode ter o

desempenho prejudicado pois o hypervisor controla os processos e todas as

requisições de hardware.

Para (LAUREANO, 2006) a virtualização total (Figura 26) constrói no

ambiente virtual todo o hardware necessário ao sistema convidado correspondendo

a um sistema real existente. Toda a interface de acesso é virtualizada inclusive as

instruções do processador e os dispositivos de hardware.

Figura 26 ‐ Representação da virtualização total (LAUREANO, 2006)

Segundo os autores (LAUREANO, 2006; VERAS, 2011) a virtualização total

possuí algumas desvantagens:

O fato das instruções não serem modificadas faz com que o hypervisor

tenha que testá-las para avaliar se são instruções sensíveis ou não, pois

instruções sensíveis necessitam interpretação e emulação no sistema

nativo para evitar que a máquina virtual não modifique o comportamento

do sistema;

O sistema virtualizado é executado de forma mais lenta e o hypervisor

precisa implementar alternativas para que operações privilegiadas sejam

35

executadas em processadores que não suportam virtualização de forma

nativa.

1.7.6.2. Paravirtualização

A paravirtualização ou virtualização assistida por SO como também é

conhecida (Figura 27) envolve a modificação do kernel do SO. O intuito desta

modificação é trocar instruções não virtualizadas por hypercalls que se comunicam

diretamente com a camada de virtualização do hypervisor, como resultado melhora-

se a comunicação entre o SO convidado e o hypervisor obtendo assim maior

eficiência e desempenho. (VMware, 2007)

Figura 27 ‐ A abordagem de paravirtualização para a virtualização x86 (VMware, 2007)

A paravirtualização (Figura 28) difere da virtualização total na qual o SO

convidado não sabe que está sendo virtualizado e chamadas de sistema sensíveis

(instruções sensíveis) são executadas através de translação binária. (VMware, 2007)

36

Figura 28 ‐ Representação da paravirtualização (LAUREANO, 2006)

1.7.6.3. Virtualização Total e Paravirtualização

Com a virtualização total o hypervisor possuí um trabalho complementar ou

adicional para conduzir a gerência da memória. Basicamente o hypervisor aloca um

espaço de memória, entretanto o sistema convidado acredita estar no começo da

memória e deste modo o hypervisor precisa “traduzir” os endereços todas as vezes

que o sistema convidado efetuar algum acesso à memória. (LAUREANO, 2006)

Figura 29 ‐ Alocação de memória para sistema convidado (LAUREANO , 2006)

37

Na paravirtualização o processo descrito anteriormente não ocorre devido ao

fato de que o hypervisor “informa” ao sistema convidado o espaço de memória a ser

utilizado. (LAUREANO, 2006)

1.7.6.4. Virtualização Assistida por Hardware

Os sistemas de virtualização programam diversas técnicas para prover a

virtualização fazendo com que os SOs convidados sejam executados no Ring 1 ou 3

(Figura 30).

Figura 30 ‐ Estrutura do funcionamento da máquina virtual em um processador x86 (LAUREANO, 2006)

Entretanto as técnicas utilizadas resultam em alguns problemas:

Introduz sobrecarga considerável para a tradução de instruções na

virtualização total;

Requer alteração nos sistemas convidados com a técnica de

paravirtualização, limitando a compatibilidade e suporte.

A virtualização assistida por hardware (Figura 31) é aplicada diretamente nos

processadores da arquitetura x86 e foi desenvolvida como uma iniciativa dos

fabricantes de processadores (AMD e Intel) para suportar de forma nativa a

virtualização e aumentar o desempenho da solução virtualizada.

O intuito é introduzir um recurso para execução do processador que permita

ao hypervisor executar em um novo modo privilegiado abaixo do Ring 0, fazendo

com que instruções sensíveis sejam entregues automaticamente ao hypervisor

eliminando assim a necessidade de translação binária ou paravirtualização.

38

Figura 31 ‐ A abordagem assistida por hardware para a virtualização x86

1.7.6.5. Recompilação Dinâmica

Com a recompilação dinâmica o sistema consegue adequar o código (ou

parte dele) gerado durante a execução e permitir a criação do ambiente nativo

(original) do programa. O sistema anfitrião analisa, explora, reorganiza e traduz as

instruções do sistema convidado em novas sequencias de instruções na medida em

que a execução do sistema convidado avança. (LAUREANO; MAZIERO, 2008)

Segundo (LAUREANO; MAZIERO, 2008) a recompilação dinâmica é formada

por sete etapas:

Agrupamento de bits;

Desmontagem;

Geração intermediária do código;

Decompilação;

Compilação;

Montagem;

Armazenagem dos bits.

39

1.7.7. Benefícios

A implementação de um ambiente virtualizado pode ser justificada com o fato

de que provisionar novos servidores, reduzir o consumo de energia, melhorar o

aproveitamento de recursos e a carência de uma estratégia de recuperação de

desastre são fatores beneficiados com a implementação da virtualização. (VERAS,

2011)

Com a virtualização diversos benefícios são obtidos:

Otimização dos recursos de hardware: os recursos dos servidores são

melhor aproveitados com a implementação de diversas máquinas virtuais

em um único servidor, fazendo com que o tempo de ociosidade dos

sistemas diminua.

Flexibilidade na criação de novas máquinas virtuais: o processo de

instalação e configuração de um novo servidor que envolve levantamento

de custos e aprovações pode ser facilmente melhorado pelo fato de que

máquinas virtuais podem ser criadas rapidamente em um servidor físico já

em produção.

Padronização das plataformas: com a existência de um monitor de

máquinas virtuais a integração de diferentes plataformas se torna

possível, pois é implementada uma camada de abstração que permite

total isolamento dos sistemas que são executados em um mesmo

hardware físico.

Gerenciamento centralizado: torna o ambiente de gerenciamento

menos complexo, pois todo o ambiente é centralizado e gerenciado por

uma única ferramenta.

Permite aumentar taxas de consolidação: ambiente antes 1:1 se

tornaram ambientes N:1.

Redução do uso do espaço físico: com a implementação de um

ambiente virtualizado o ganho em espaço é uma consequência, pois na

medida em que mais aplicações são migradas para servidores virtuais a

quantidade de servidores físicos tende a diminuir.

40

Redução do consumo de energia: um ganho proporcionado em

conjunto com a consolidação, pois os servidores são responsáveis por

grande parte do consumo de energia.

Isolamento de ambientes (teste, homologação e produção): a

construção de ambientes físicos de teste homologação e produção é uma

tarefa cara e que é melhor dimensionada com a utilização da virtualização

que permite a construção desses ambientes de forma totalmente isolada

e em poucos servidores físicos.

Ferramenta de apoio à recuperação de desastres: facilita a alocação

de recursos para o site secundário e também melhora consideravelmente

o RTO para restauração dos ambientes.

Os benefícios descritos estão relacionados com a melhora ou redução do

TCO (Total Cost of Ownership), que com a virtualização viabiliza ganhos em vários

aspectos para melhoria da infraestrutura de forma prática e com o fator de redução

considerável de custos. (VERAS, 2011)

1.7.8. Aplicações

Dentre diversos contextos e para diversos fins é possível utilizar a tecnologia

de máquinas virtuais, podendo-se destacar:

Ensino;

Consolidação de servidores;

Plano de contingência;

Migração de aplicações;

Confinamento de processos;

Honeypots e Honeynets;

Detecção de intrusão;

Serviços de hosting (hospedagem).

41

1.7.9. Limitações

Apesar dos benefícios proporcionados com a utilização da virtualização,

existem algumas dificuldades para adoção de uma solução virtualizada:

(LAUREANO, 2006)

Processador não virtualizado: a arquitetura de processadores AMD

ou Intel 32 bits não tem como característica natural a virtualização.

Diversidade de equipamentos: devido a vasta quantia de

equipamentos disponíveis e considerando uma execução normal o

hypervisor precisaria controlar todos os dispositivos o que aumenta a

complexidade no desenvolvimento dos mesmos.

Preexistência de software: um ambiente composto por PCs com um

SO padrão utilizado pela maioria dos usuários e suas funcionalidades

que permitem ao usuário final customizar as configurações são

características que precisam ser mantidas com a implementação de

um ambiente virtualizado.

(VERAS, 2011) também aponta algumas limitações quanto à implementação

da virtualização:

Aplicativos de carga excessiva: considerando que o hypervisor também

introduz perda de desempenho, aplicativos como sistemas gerenciadores

de banco de dados (SGBD) exigem grande parte dos recursos

computacionais de um servidor durante boa parte do tempo. Neste caso a

virtualização pode não ser a solução mais viável.

Gerenciamento do licenciamento: pode se tornar um item que imponha

limitações, como não há um padrão entre os fabricantes das mais

diversas aplicações comumente utilizadas é preciso conhecer

precisamente a regra para cada aplicação.

Falta de profissional especializado: Fator a ser considerado na escolha

da ferramenta de virtualização, pois profissionais experientes na área de

virtualização não são facilmente encontrados.

42

1.7.10. Emulação e Virtualização

O conceito de emulação difere de virtualização. Um emulador tem por função

simular um computador real transcrevendo as instruções de um processador em

outro processador, e implementar estas instruções em um ambiente abstrato de

software permitindo que um aplicativo desenvolvido para uma plataforma específica

funcione em outra plataforma. Basicamente durante o processo de emulação o

emulador interpreta o código desenvolvido para outra plataforma (recompilação).

Em uma máquina virtual o processo de virtualização ocorre em um nível de

abstração intermediário entre uma máquina real e um emulador. Um monitor de

máquina virtual provê uma interface (multiplexação de hardware) idêntica ao

hardware subjacente enquanto que um emulador fornece uma camada de abstração

completa entre o sistema em execução e o hardware.

Os emuladores perdem em eficiência durante o processo de interpretação das

instruções e possuem alto grau de complexidade em seu processo de

desenvolvimento, pois simulam praticamente todas as instruções do processador e

do hardware os quais irão emular. (LAUREANO, 2006)

1.7.11. Abstração e Virtualização

Também existe uma diferença entre os conceitos de abstração e virtualização

mesmo descrevendo a virtualização como uma abstração em software, o processo

de abstração propriamente dito é uma maneira não complexa de prover recursos de

hardware para um software, já a virtualização provê um conjunto completo desses

recursos.

43

Figura 32 ‐ Diferença entre abstração e virtualização (LAUREANO, 2006)

Como descrito na Figura 32 no processo de abstração os softwares acessam

os arquivos e desempenham operações simples (leitura ou escrita por exemplo), já a

virtualização permite realizar operações mais complexas (mkdir ou chmod, por

exemplo), pois fornece ao software um disco virtual. (LAUREANO, 2006)

1.7.12. Ferramentas e Fornecedores

De acordo com uma pesquisa realizada em 2008 pelo ESG (Enterprise

Strategy Group) entre grandes organizações nos Estados Unidos e obtendo-se um

total de 365, e pode-se constatar que as organizações pesquisadas utilizam a

virtualização para obter benefícios de alguma maneira. (BOWKER; LALIBERTE,

2008; VERAS, 2011)

44

Gráfico 2 ‐ Fatores que impulsionam a virtualização(Bowker & Laliberte 2008, traduzido)

Os diversos fatores analisados evidenciam o fato de que a virtualização se

torna cada vez mais uma prática comum e ao mesmo tempo mais empresas

começam a adentrar um mercado que ainda tem a VMware como líder de mercado.

É possível visualizar no quadrante mágico da Gartner que VMware, Microsoft e Citrix

respectivamente constituem maior abrangência de utilização dentre as soluções

existentes de virtualização.(BITTMAN et al., 2010)

45

Figura 33 ‐ Quadrante mágico para virtualização x86 (WEISS et al., 2011)

As ferramentas mais utilizadas são:

VMware: VMware ESXi, Server e Workstation;

Microsoft: Hyper-V e Virtual PC;

Citrix: Xen Server;

Ainda pode-se observar que algumas empresas fornecem soluções para

atender um determinado nicho de mercado como, por exemplo:

Oracle: Oracle VM e Virtual Box;

Red Hat: Red Hat Enterprise Virtualization Server;

Parallels: Virtualização na plataforma Mac OS;

Novell: Implementação do Xen e do KVM (Kernel-based Virtual

Machine) no Suse Linux Enterprise.

46

CAPÍTULO 2 – METODOLOGIA

2.1 DEFINIÇÃO DO AMBIENTE

A definição do ambiente baseou-se na utilização de um “Desk Server” para

ser o servidor de testes tendo em vista que não foi possível ter acesso a um servidor

propriamente dito.

Em poder do hardware foi analisado qual seria a melhor forma de fazer um

estudo prático comparativo entre ambientes virtualizados e não virtualizados e qual o

impacto ocasionado no RTO e desempenho.

2.1.1 Hardware Utilizado

Especificações:

Processador: AMD Phenom X4 9500 Black Edition; 4 núcleos de 2,2

GHz cada;

Memória Cache: L1 64 KB, L2 512 KB e L3 2 MB;

Placa–mãe: FOXCONN M61PMV;

Memória: 4 GB DDR 2; 800 MHz frequência;

Disco: Seagate Barracuda; 160 GB Sata; 7200 RPM;

Disco Backup: Samsung; 500 GB Sata; USB externo;

Chipset Placa-mãe: nVIDIA nForce 6100-430, AMD K10;

Placa de Rede: nVIDIA nFORCE 10/100 Mbps;

Internet: Telefônica Speedy 4 Mbps.

O hardware descrito refere-se a um microcomputador desktop produzido no

Brasil pela empresa EZPAC.

2.1.2 Servidor de E-mail

Os fatores que resultaram na escolha de um ambiente com servidor de e-mail

foram:

47

Fundamentar o trabalho de forma a se aproximar de um ambiente

corporativo real, pois atualmente todas as empresas possuem o e-mail

como uma das principais ferramentas para condução do

negócio;(CAIN, 2010)

Avaliar a aplicação inteira (full stack), com testes entre o servidor o

Microsoft Outlook 2003, 2007 e webmail (Outlook Web Access ou

somente OWA);

Não foi encontrada uma ferramenta gratuita de benchmark específica

para avaliação de servidor de e-mail, diferentemente de servidores web

(Httperf, ApacheBench, Http Load, etc), banco de dados (DB Monsters,

DB Sanity, etc) e servidores de aplicação (Apache Jmater, CLIF,

Grinder, etc).(“Open Source Software Testing Tools”).

O Exchange Server 2007 foi escolhido como servidor de e-mail, pois segundo

(CAIN, 2010) a plataforma Microsoft Exchange é o servidor de e-mail mais utilizado

mundialmente nos ambientes corporativos, além disso, por se tratar de uma solução

Microsoft utiliza a base de usuários do Active Directory, facilitando assim o

gerenciamento e controle.

O Exchange Server 2007 possui alguns pré-requisitos que viabilizam sua

instalação:

.NET Framework 2.0;

Microsoft Management Console (MMC);

Microsoft Windows PowerShell;

Microsoft Windows Installer;

Após a instalação do Exchange Server 2007, realizar atualizações

críticas.

A figura 34 ilustra a instalação e a validação dos pré-requisitos do Exchange

Server 2007:

48

Figura 34 ‐ Pré‐requisitos Exchange Server 2007

2.1.3 Sistema Operacional

O servidor de e-mail escolhido se trata de uma solução Microsoft, por este

motivo com o intuito de executar testes precisos e obter resultados com eficiência o

SO definido como o sistema base de execução dos experimentos deste trabalho de

conclusão de curso foi o Windows Server 2008 Datacenter Edition (Figura 35).

Figura 35 ‐ Windows Server 2008 Datacenter Edition(“Microsoft Corporation”)

49

O motivo da escolha da versão Datacenter Edition é devido ao fato desta

apresentar as mesmas características da versão Enterprise, entretanto possuí como

vantagem o número ilimitado de SOs virtualizados, sendo que nas versões Standard

e Enterprise este número limita-se em 1 e 4 respectivamente.(“Windows Server

2008: Visão Geral das Edições”)

Outro fator que levou a escolha deste sistema foi a gama de ferramentas da

plataforma Microsoft de soluções possuírem administração centralizada e melhor

integração entre si.

Figura 36 ‐ Microsoft integração entre ferramentas (“Integração Microsoft Active Directory”)

Dentre as ferramentas integradas ao Windows Server Datacenter Edition as

seguintes funções foram configuradas para viabilizar a execução dos testes:

Active Directory Domain Services (ADDS);

Application Server (AS);

DNS (Domain Name System);

File Services;

50

Web server (IIS).

2.1.4 Microsoft Exchange Server Load Generator

Ferramenta para execução de carga da Microsoft utilizada em conjunto com o

Exchange Server 2007 e 2010. O Microsoft Exchange Server Load Generator

(MELG) é utilizado no período de dimensionamento do servidor para averiguar a

capacidade de usuários que o mesmo pode suportar simultaneamente sem

sobrecarregá-lo. (Microsoft).

2.1.5 Monitoramento de Desempenho

A ferramenta de monitoramento de desempenho utilizada foi o Windows

Performance Monitor ou WPM, ferramenta já integrada ao Windows.

O WPM é utilizado para analisar em tempo real ou através de logs como os

programas em execução afetam o desempenho do computador. O WPM usa

indicadores de performance (objetos e contadores), dados de rastreamento de

eventos e informações de configuração que combinados geram relatórios e gráficos.

(TECHNET)

2.2 FERRAMENTAS DE VIRTUALIZAÇÃO UTILIZADAS

Os hypervisores do tipo I e II escolhidos para realização dos testes foram:

Tipo I: Citrix Xen Server 5.6, Microsoft Hyper-V 2008 , VMWare ESXi

4.0;

Tipo II (sistema hospedeiro Windows XP 64 bits): Oracle Virtual Box

4.0.10, VMware Server 2.0.1, Microsoft Virtual PC 2007

2.2.1 Citrix Xen Server

O Citrix Xen Server é a plataforma completa de virtualização da Citrix

desenvolvida utilizando o hypervisor Xen.

51

Empregando a técnica de paravirtualização a ferramenta da Citrix possuí

vasto reconhecimento pela velocidade para criação das máquinas virtuais,

segurança presente no software de virtualização e também por suportar virtualização

assistida por hardware dos processadores Intel - VT e AMD - V.

O Citrix Xen Server é uma solução para implementação em qualquer

datacenter, e pode ser usado para converter máquinas físicas em novas máquinas

virtuais e migrá-las para o ambiente do Xen Server. (Citrix, 2011)

Requisitos do Sistema:

Processador: mínimo de 1.5 GHz e recomendado 2 GHz com mais de

um núcleo. Necessário suporte a virtualização assistida por hardware

para virtualização de máquinas Windows.

Memória: mínimo 1 GB e máximo 128 GB.

Placa de rede: mínimo uma de 10/100 Mbps.

Disco: mínimo 16 GB de espaço e recomendado 60 GB ou mais.

(Citrix, 2010)

Limitações:

Placas de rede por servidor físico: máximo 16.

Placas de rede virtuais por máquina: 7 (Windows) e 3 (Linux).

Discos virtuais por máquina: 7 (com o XenServer Tools instalado – 3

sem o XenServer tools).

Drive de cd virtual:1.(Citrix, 2010)

2.2.2 Microsoft Hyper-V

Com a necessidade de uma solução de virtualização mais eficiente e flexível

e com melhor integração com as ferramentas de gerenciamento mais utilizados

pelos administradores de TI, a Microsoft desenvolveu o Hyper-V, um hypervisor de

tipo I integrado ao Windows Server 2008.(“Microsoft Hyper-V Server”)


Processador: Mínimo 2 GHz 64 bits com suporte a virtualização

assistida por hardware.

52

Memória: Mínimo 1 GB e recomendado 2 GB ou mais.

Placa de rede: Mínimo uma de 10/100 Mbps e recomendado duas ou

mais.

Disco: Mínimo 10 GB e recomendado 40 GB ou superior. (“Microsoft

Hyper-V Server: System Requirements”)

Limitações:

Memória por servidor físico: 1 TB (Windows Server 2008 Enterprise

e Datacenter) e 32 GB (Windows Server 2008 Standard).

Memória por máquina virtual: 64 GB por máquina virtual (Windows

Server 2008 Enterprise e Datacenter) e 31,5 GB para todas as

máquinas virtuais (Windows Server 2008 Standard).

Processadores por servidor físico: até 16 processadores lógicos.

Processadores virtuais por máquina: até 4 processadores.

Tamanho de disco virtual por máquina: até 2 TB.

Placas de rede virtual por máquina: máximo 12. (“Hyper-V Maximum

Supported Configurations”)

2.2.3 VMware ESXi

O VMware ESXi é a nova geração de hypervisores da VMware. Esta nova

geração introduz uma arquitetura inovadora que opera de forma independente de

qualquer SO, oferecendo mais segurança, confiabilidade e gerenciamento

simplificado. A arquitetura compacta foi concebida para integração direta com o

hardware, viabilizando rápida instalação, configuração e implementação.(VMware)


Processadores suportados (64 bits):

o Todos os AMD Opterons.

o Todos os Intel Xeon 3000/3200, 3100/3300, 5100/5300,

5200/5400, 7100/7300, e 7200/7400.

o Todos os Intel Nehalem.

Memória: mínimo 2 GB

Placa de Rede: mínimo uma de 10/100/1000 Mbps. (VMware, 2009)

53

Limitações:

Memória por servidor físico: máximo1 TB.

Memória por máquina virtual: máximo 255 GB.

Disco: máximo 2 TB.

Processadores por máquina virtual: máximo 8.

Máquinas virtuais por servidor físico: máximo 320.

Placas de rede por máquina virtual: máximo 10.(VMware, 2011)

2.2.4 Oracle Virtual Box

O Oracle VM VirtualBox é um hypervisor do tipo II para virtualização em

desktops que permite a execução de várias máquinas virtuais e é compatível com

diversos SOs. Suporta o desenvolvimento e teste de aplicações multi-plataforma e

aceleração gráfica 2D/3D.(“Oracle Vm Virtualbox”)


Qualquer processador compatível com a arquitetura x86, 32 ou 64 bits

(versão 4.0.10), com ou sem suporte a virtualização assistida por hardware e que

tenha ao menos 1 GB de memória.(Oracle, 2010)

Limitações:

Processadores virtuais por máquina: máximo 8 (recomendado não

ultrapassar a quantidade existente no sistema hospedeiro).

Memória virtual por máquina: recomendado não ultrapassar 80% da

memória do sistema hospedeiro. (Oracle, 2010)

2.2.5 VMware Server

O VMware Server é um hypervisor de tipo II instalado como uma aplicação

(processo) em um sistema hospedeiro. Uma camada de virtualização particiona o

servidor físico permitindo que várias máquinas virtuais sejam executadas ao mesmo

54

tempo em um único servidor. Trata os recursos do servidor físico como um conjunto

uniforme, permitindo que sejam alocados de uma maneira controlada.

O VMware Server consegue isolar as máquinas virtuais entre elas e o

sistema hospedeiro, outro recurso importante presente na ferramenta é o

encapsulamento do ambiente de máquina virtual em um conjunto de arquivos,

facilitando o backup e movimentação de arquivos.(“VMware Server”)

Requisitos do Sistema: processadores compatíveis com a arquitetura x86,

32 ou 64 bits, com pelo menos 733 MHz.(“VMware Server Online Library”)

Limitações:

Máquinas virtuais por servidor físico: 64 (recomendado não

executar mais do que 4 máquinas virtuais por processador).

2.2.6 Microsoft Virtual PC

O Microsoft Virtual PC é um hypervisor de tipo II da Microsoft para

virtualização. O Virtual PC foi descontinuado pela Microsoft que atualmente tem

como ferramenta principal de virtualização o Hyper-V.(“Microsoft Virtual PC 2007

SP1 Guest OS”)


Processador: Mínimo 1 GHz.

Disco: Utiliza 35 MB.(“Microsoft Virtual PC 2007 SP1 Guest OS”)

2.3 INDICADORES ANALISADOS

2.3.1 Tempo de Recuperação

O tempo de recuperação utilizado para restaurar os sistemas e recursos

interrompidos (RTO) este indicador mostrará a diferença para restauração de um

ambiente virtualizado e um ambiente que não possuí virtualização. Com este

indicador será avaliado se o RTO do ambiente virtualizado é inferior, igual ou

superior em relação ao ambiente não virtualizado.

55

2.3.2 Performance e Desempenho

O intuito dos testes de medição de desempenho é avaliar o comportamento

do servidor numa situação real, provocando no mesmo alta utilização dos recursos

com o objetivo de quantificar a performance e comportamento do servidor de e-mail

Exchange Server 2007.

Os testes foram executados para medir o desempenho entre o ambiente

virtualizado com hypervisores do tipo I e II e em um ambiente não virtualizado e

fazer um comparativo entre as ferramentas de virtualização. Os indicadores de

performance (objetos) utilizados foram:(TECHNET)

Processador:

o % Processor Time: determina o tempo que o processador está

ocupado ou em utilização, este indicador mede a porcentagem

de tempo que a thread do processo IDLE é executada e subtraí

este tempo de 100 %. Deve ser inferior a 75%

o % User Time: mostra a porcentagem de tempo gasto por uma

thread executada em modo usuário. Deve ser inferior a 75%.

Memória:

o Available Mbytes: indica a quantidade de memória física

disponível (livre) para uso imediato por um processo ou pelo

sistema operacional. Deve permanecer acima de 100 MB em

todos os momentos.

o Comitted Bytes: este indicador mostra a quantidade de

memória virtual sendo utilizada.

o Page Faults / Sec: quantidade de page faults por segundo que

ocorrem devido ao fato de uma determina página de memória

não estar na memória física e uma thread tentar acessá-la.

56

Disco (lógico e físico):

o Current Disk Queue Length (lógico): mostra o número de

requisições pendentes no disco no momento em que dados de

performance são coletados. Este indicador pode refletir um

transitório comprimento de fila, mas se houve uma carga

sustentada no disco é provável que ele permaneça alto.

o Average Disk Bytes/Read: média de bytes transferidos do

disco durante operações de leitura.

o Average Disk Bytes/Write: média de bytes transferidos do

disco durantes operações de escrita.

o % Idle Time: porcentagem de tempo durante o intervalo que o

disco estava no estado ocioso.

MS Exchange IS:

o RPC Averaged Latency: indica a latência média de RPC para

todas as operações dos últimos 1024 pacotes. Não deve ser

superior a 25 ms.

o RPC Requests: indica o total de solicitações RPC que estão

sendo executadas dentro do processo de armazenamento de

informações. Deve ser inferior a 70 em todos os momentos.

MS Exchange IS Mailbox:

o Local Delivery Rate: A taxa média a qual as mensagens são

entregues localmente ao Exchange Store.

2.4 LINHA DE TRABALHO

Em ordem de trabalho os testes foram realizados com a máquina física,

hypervisores do tipo I e II respectivamente.

2.4.1 Ambiente não-virtualizado

Instalação do SO, atualizações (Windows Update) e configuração dos

serviços e pré-requisitos para o servidor de e-mail Exchange Server;

57

Instalação e configuração do servidor de e-mail Exchange Server e

atualizações respectivas;

Execução dos testes de desempenho utilizando o Windows

Performance Monitor e Microsoft Exchange Server Load Generator e

coleta dos resultados obtidos;

Backup completo do ambiente de teste em disco externo;

Crash do ambiente, restauração e verificação do tempo de

recuperação.

2.4.2 Ambiente virtualizado

Para os hypervisores do tipo I os procedimentos adotados foram:

Microsoft Hyper-V:

o Instalação do Windows Server 2008 Datacenter 64 bits;

o Instalação da função Hyper-V;

o Atualização do sistema operacional e Hyper-V;

o Instalação do cliente de configuração e gerenciamento em um

PC cliente;

o Criação da máquina virtual;

o Execução dos procedimentos realizados no ambiente não-

virtualizado (2.4.1).

Citrix Xen Server:

o Instalação do Citrix Xen Server

o Instalação do cliente de configuração e gerenciamento em um

PC cliente;


o Execução dos procedimentos realizados no ambiente não

virtualizado (2.4.1).

VMware ESXi:

o Instalação do VMware ESXi

o Abortado o teste do ambiente devido à falha (3.1.1);

Para os hypervisores do tipo II os procedimentos adotados foram:

58

VMware Server:

o Instalação do SO host (Windows XP 64 bits);

o Atualização do SO (Windows Update);

o Instalação do hypervisor;



virtualizado (2.4.1), exceto backup completo, crash e verificação

do tempo de recuperação do ambiente devido à falha

encontrada (3.1.2).

Oracle Virtual Box:






virtualizado (2.4.1), exceto backup completo, crash e verificação

do tempo de recuperação do ambiente devido à falha

encontrada (3.1.4).

Microsoft Virtual PC:





o Abortado o teste devido à incompatibilidade (3.1.3).

2.4.3 Instalação do SO, atualizações (Windows Update) e configuração dos serviços e pré-requisitos para o servidor de e-mail Exchange Server

Para a instalação do Windows Server 2008 o HD foi dividido em duas

partições com 65 GB cada, sendo a unidade C: utilizada para instalação do sistema

operacional e a unidade D: deixada reservada para instalação do Exchange Server.

O sistema de arquivos utilizado foi o NTFS.

Durante a instalação foi escolhido o idioma inglês para o sistema operacional,

formato de data e hora em Português (Brasil) e teclado ABNT II.

59

A versão escolhida para instalação do SO foi a Datacenter 64 bits completa

(Full Installation).

Após a instalação do SO foi configurada a senha de administrador para o

mesmo, finalizando o procedimento de instalação.

Não houve a necessidade de instalar nenhum driver de terceiro, pois o

Windows Server reconheceu automaticamente os dispositivos e instalou os

respectivos drivers não necessitando de intervenção do usuário.

Após a instalação do SO, o nome da máquina foi alterado para MAIL,

configurado IPv4 fixo para conexão local e as funções e serviços necessários para o

Exchange Server 2007.

As primeiras funções e serviços instalados foram o ADDS e o DNS. Para

inicialização da instalação de ambos foi inserido o comando dcpromo.exe no

executar do Windows, e seguida a sequencia de configuração:

1. Utilização de modo de instalação avançado (Use advanced mode

installation);

2. Criação de um novo domínio em uma nova floresta (create a new

domain in a new forest);

3. Cadastrado o nome do domínio (FQDN) como contoso.com;

4. Cadastrado o nome NetBIOS como CONTOSO;

5. Nível funcional da floresta como Windows Server 2003;

6. Nível funcional do domínio como Windows Server 2003;

7. Opções adicionais escolhidas: DNS Server e Catalogo Global;

8. Pasta da base de dados e logs: C:\windows\NTDS;

9. Pasta de SYSVOL: C:\windows\SYSVOL

10. Senha do modo de restauração do diretório de serviços;

11. Reinicialização do SO.

Após a reinicialização do SO as demais funções e serviços necessários para

o funcionamento do Exchange Server 2007 foram adicionados através do assistente

de configuração de funções (Add Roles Wizard):

60

1. Escolhidas as funções Application Server, File Services e Web Server;

2. Em Application Server foi escolhido o serviço Application Server

Foundation;

3. Em Web Server foram escolhidos os serviços: Static Content, Default

Document, Directory Browsing e HTTP Errors em Commom HTTP

Features; ASP.NET, .NET Extensibility, ISAPI Extensions, ISAPI Filters

em Application Development; HTTP Logging, Request Monitor em

Health and Diagnostics; Basic Authentication, Digest Authentication,

Client Certificate Mapping Autentication, URL Authorization, Request

Filtering e IP and Domain Restrictions em Security; Static Content

Compression e Dynamic Content Compression em Performance; IIS

Management Console, IIS Management Scripts and Tools,

Management Service, IIS6 Management Compatibility em Management

Tools;

4. Em File Services foi escolhido o serviço File Server.

Após a conclusão da instalação e a reinicialização do SO, mais funções foram

instaladas:

1. NET Framework 3.0 Features, Desktop Experience, Windows

PowerShell e Windows Server Backup Features (apenas no ambiente

não virtualizado)

2. Instalação do Windows Installer 4.5;

3. Atualização do SO através do Windows Update.

2.4.4 Instalação e configuração do servidor de email Exchange Server e

atualizações respectivas

Após a instalação dos requisitos do Exchange Server (2.4.3) a versão 2007

com SP3 foi instalada e configurada da seguinte maneira:

1. Escolher o modo customizado de instalação (custom Exchange Server

Installation);

2. Alterado o caminho de instalação para D:\Exchange;

3. Escolhidas as seguintes funcionalidades: Mailbox Role, Client Access

Role, Hub Transport Role, Unified Messaging Server Role;

61

4. Em Exchange Organization configurado como CONTOSO;

5. Escolhido SIM na opção de configuração de clientes para o Outlook

2003 ou anterior e Entourage (cliente Outlook para Mac OS);

Após o termino da instalação foi executado o Windows Update para instalar

os últimos pacotes de correção para o produto.

Com todo o sistema instalado e devidamente configurado foi criado um

arquivo .csv com 600 usuários os quais foram utilizados no teste de performance e

desempenho do Exchange Server 2007, esta quantidade de usuários foi escolhida

pois esse número de usuários engloba 99,8% das empresas instaladas no

Brasil.(IBGE, 2009)

Esse arquivo .csv foi gerado a partir de um programa em C com código

abaixo:

#include <stdio.h> main(){ int i; printf("Alias,Name,VPN \n"); for(i=1;i<=600;i++){ printf("Fatec%03d,Fatec%03d,fatec%[email protected]\n",i,i,i); } }

Obtendo como saída:

Alias,Name,VPN

Fatec001,Fatec001,[email protected]



...


E através do Exchange Management Shell definido uma senha padrão para

esses usuários com o comando:

$Password = Read-Host “Entre com a senha padrão para as novas

contas:” –AsSecureString

62

A senha deve ter pelo menos 8 caracteres, um caractere especial e pelo

menos um número devido a imposição de segurança do sistema operacional

Windows Server 2008, caso seja necessário alterar esses requisitos deve ser feito

editando as políticas de senha no Group Policy Management.

Os usuários foram importados do .csv com o comando:

Import-Csv user.csv | foreach { new-mailbox -alias $_.Alias -name

$_.Name -UserPrincipalName $_.VPN -Database "Mailbox Database" -

OrganizationalUnit contoso.com/Users -Password $Password -

ResetPasswordOnNextLogon:$false }

Devido a integração do Exchange Server 2007 com o ADDS, os usuários

cadastrados foram automaticamente criados em ambos os sistemas, e para fins de

testes separados em 3 grupos: Outlook 2003 e Outlook 2007 com 100 usuários cada

e os 400 restantes deixados no grupo Users.

2.4.5 Execução dos testes de desempenho utilizando o Windows Performance Monitor e Exchange Load Generator e coleta dos resultados obtidos Para execução dos testes de desempenho primeiramente foi executado o

programa Windows Performance Monitor (Figura 37) e inseridos os indicadores

mostrados no item 2.3.2 com uma escala de tempo de uma hora de coleta e após

uma hora de execução os indicadores foram colhidos e tabulados (3.1)

63

Figura 37 ‐ Windows Performance Monitor

Para a geração de carga de trabalho no Exchange Server 2007 foi utilizado o

programa Microsoft Exchange Server Load Generator (MELG) que foi configurado

da seguinte maneira:

64

Figura 38 ‐ Tela de configuração da duração do teste no Microsoft Exchange Server Load Generator

define the length of a ‘simulation day: é o total de horas da carga de

um dia de trabalho e o define the total length of the simulation é o

tempo total que o mesmo irá executar o teste (Figura 38).

Também foi optado que o MELG criasse uma lista de distribuição dinâmica

com todos os usuários cadastrados para poder ser utilizada durante os envios dos e-

mails de testes.

Durante o período de testes, 3 grupos para execução da carga de trabalho

foram definidos que são cliente Outlook 2003 Online, Outlook 2007 Online e o cliente

via web OWA (Figura 39).

65

Figura 39 ‐ Grupo de clientes

Ao final do processo de configuração é gerado um resumo com as opções

escolhidas. (Figura 40)

Figura 40 ‐ Resumo da configuração do MELG

66

Após a correta configuração basta clicar em Start the initialization followed

by simulation e após a execução do teste obtivemos a seguinte saída:

Figura 41 – Saída do MELG

Com os dados coletados nesta fase poderemos analisar quais as diferenças

de desempenho entre os ambientes analisados, fazendo assim um comparativo

entre eles.

2.4.6 Backup do Ambiente

Em todos os ambientes utilizados (virtualizado e não-virtualizado) foi efetuado o

backup do ambiente para um disco rígido SATA externo ligado através de uma porta

USB 2.0 (400 Mbps).

67

O backup escolhido foi o do tipo completo do ambiente, onde no virtualizado foi

feito uma exportação da máquina virtual e disco virtual para o HD externo e no não

virtualizado utilizado a ferramenta Windows Server Backup. Os procedimentos

adotados de acordo com o ambiente foram:

Máquina Física:

1. Backup customizado;

2. Selecionados os volumes C:\ (SO) e D:\ (Exchange Server);

3. Escolhida a execução imediata do Backup;

4. Configurado o local de armazenamento do backup como o disco

rígido externo;

5. Inicializado o Backup e gerado um arquivo de recuperação de

84GB.

Citrix Xen Server:

1. Acessado o servidor via SSH;

2. Criado o diretório para montagem do HD externo:

mkdir /mnt/usb

3. Montado o disco rígido externo:

mount /dev/sdb /mnt/usb

4. Exportado a máquina virtual e o disco virtual:

xe vm_export_vm=exchange filename=/mnt/usb/exchange.xva

5. O arquivo gerado foi de 84,2 GB.

Microsoft Hyper-V

1. Exportado a maquina virtual e o disco virtual:

Através da GUI de gerenciamento clicado em Export

2. Escolhido o caminho de exportação

F:\

3. O arquivo gerado foi de 84,3 GB

68

VMware Server, Oracle Virtual Box, Microsoft Virtual PC e VMware

ESXi:

Não foi executado backup nesses ambientes devido a falhas ocorridas

durante o processo de instalação e/ou teste (3.1)

2.4.7 Crash do Ambiente e Verificação do Tempo de Recuperação (RTO) O crash do ambiente consistiu em efetuar a perda total dos dados do

ambiente em produção simulando assim uma falha de hardware, ataque mal-

intencionado ou desastre natural.

Para isso ocorrer foi efetuado a formatação do disco host, reinstalação do

sistema base de acordo com o ambiente, restauração do backup e contabilização do

tempo de recuperação (RTO)

Os procedimentos adotados foram:

Máquina Física:

1. Instalação do SO Windows Server 2008 e requisitos para o

Exchange Server (item 2.5.3);

2. Instalação do Exchange Server e atualizações;

3. Restauração do backup dos usuários e caixas postais respectivas;

4. Tempo total gasto: 06h11.

Microsoft Hyper-V:

1. Instalação do SO Windows Server 2008;

2. Instalação do Hyper-V;

3. Atualização do SO e Hyper-V;

4. Restauração da máquina virtual efetuando a cópia do arquivo

exportado para o diretório padrão de configuração de máquina

virtual (C:\ProgramData\Microsoft\Windows\Hyper-V) e disco rígido

da máquina virtual (C:\Users\Public\Documents\Hyper-V\Virtual

Hard Disks);

5. Tempo total gasto: 03h45.

Citrix Xen Server:

1. Instalação do Citrix Xen Server

69

2. Criação de diretório para montagem de disco rígido externo

mkdir /mnt/usb

3. Montagem de disco rígido externo

mount /dev/sdb /mnt/usb

4. Importação da máquina virtual

xe vm_import filename=/mnt/usb/exchange.xva

VMware Server, Oracle Virtual Box, Microsoft Virtual PC e VMware

ESXi:

Não foram executados crash do sistema e verificação do tempo de

recuperação nesses ambientes devido a falhas ocorridas durante o

processo de instalação e/ou teste.

70

CAPÍTULO 3 – DISCUSSÃO E RESULTADOS

3.1. DIFICULDADES E LIMITAÇÕES ENCONTRADAS

Durante a execução da parte prática deste trabalho de conclusão de curso

algumas dificuldades em determinados ambientes e limitações impostas pelos

hypervisores foram encontradas, esses problemas fizeram com que alguns dos

ambientes não alcançassem os resultados esperados.

3.1.1. VMWare ESXi

Este hypervisor necessita de hardware homologado para seu funcionamento,

inviabilizando assim a execução dos testes. Devido a esse problema o VMware ESXi

foi removido do estudo.

3.1.2. VMware Server

Neste hypervisor o procedimento para efetuar os testes de desempenho e

verificação do RTO foram executados três vezes, porém devido a carga de trabalho

o hypervisor parou de responder (travamento do sistema) e não foi possível realizar

o procedimento para o calculo do RTO.

O VMware Server tem como limitação a utilização de apenas 2 núcleos de

processamento por máquina virtual e a memória disponibilizada as máquinas virtuais

não pode ser superior a 80% da memória da máquina física, fazendo com que nesse

caso a quantidade de memória disponibilizada para a máquina virtual fosse de

3,2 GB.

3.1.3. Microsoft Virtual PC

O Microsoft Virtual PC 2007 não possuí suporte para utilização de máquina

virtual com o SO Windows Server 2008 64 bits Datacenter.(“Microsoft Virtual PC

2007 SP1 Guest OS”; “Microsoft Virtual Pc 2007”)

71

3.1.4. Oracle Virtual Box

Com o Oracle Virtual Box três tentativas de execução do procedimento para

efetuar os testes de desempenho e a medição do RTO foram executadas. Nas duas

primeiras o hypervisor parou de responder e na última tentativa o MELG não obteve

sucesso na execução dos testes (Figura 42), sendo assim não foi gerado o

procedimento para o calculo do RTO.

Este hypervisor tem como limitação disponibilizar no máximo 80% da

memória RAM da máquina física para as máquinas virtuais, sendo assim a máquina

virtual ficou com apenas 3,1 GB de memória

Figura 42 ‐ MELG: falha na execução

3.1.5. Microsoft Hyper-V

Com o Hyper-V a única limitação encontrada foi que o hypervisor deixa

disponibilizar apenas a memória RAM livre no momento de execução da máquina

virtual e neste caso foi alocado 3,5 GB.

72

3.1.6. Citrix Xen Server

O Citrix Xen Server reservou 450 MB de memória para sua utilização,

restando 3,55 GB para uso, e para fins de compatibilidade alocado desta quantia

3,5 GB para a máquina virtual, igualando-se ao Hyper-V.

3.2. DADOS COLETADOS

Com os resultados dos indicadores coletados e tabulados, a partir dos

mesmos foram gerados gráficos para realizar a análise de desempenho e a

verificação do tempo de recuperação (RTO) entre os diferentes ambientes testados.

Apesar dos testes com o MELG no Oracle Virtual Box (Tabela 4) e no VMware

Server (Tabela 5) não serem efetuados com sucesso, foi possível obter os dados

referentes aos indicadores excetuando-se o do RTO.

Tabela 1 ‐ Dados WPM e RTO: Máquina Física

Indicador Média Mínimo Máximo Avg. Disk Bytes/Read (KB/s) 14.880,846 0 101.195,294 Avg. Disk Bytes/Write (KB/s) 12.033,890 0 63.305,963 Avaliable Mbytes (MB) 707,951 635,000 802,000 Committed Bytes (MB) 4.549,428 4.452,430 4.642,566 Page Faults/Sec (ocorrência/s) 245,776 20,232 9.304,058 RPC Requests Outstanding (un) 1,310 0 10,000 RPC Averaged Latency (ms) 2,518 2,000 29,000 RPC Requests (un) 1,224 0 9,000 Local Delivery Rate (un) 0,329 0 4,793 % Idle Time 70,552 0 99,998 Current Disk Queue Length (un) 3,179 0 145,000 % Processor Time 2,946 0 21,962 % User Time 2,148 0 14,019 RTO (horas) 06h11

73

Tabela 2 ‐ Dados WPM e RTO: Citrix Xen Server

Indicador Média Mínimo Maximo Avg. Disk Bytes/Read (KB/s) 13.144,153 0 125.829,120 Avg. Disk Bytes/Write (KB/s) 12.531,163 2.374,687 199.740,952 Avaliable Mbytes (MB) 410,781 106,000 591,000 Committed Bytes (MB) 4.731,623 4.622,709 4.957,807 Page Faults/Sec (ocorrência/s) 343,936 3,599 7.835,823 RPC Requests Outstanding (un) 0,256 0 6,000 RPC Averaged Latency (ms) 3,074 1,000 40,000 RPC Requests (un) 0,183 0 4,000 Local Delivery Rate (un) 1,202 0 5,999 % Idle Time 86,364 0 99,874 Current Disk Queue Length (un) 2,088 0 76,000 % Processor Time 7,971 0,881 41,968 % User Time 5,903 0,702 33,540 RTO (horas) 03h30

Tabela 3 ‐ Dados WPM e RTO: Microsoft Hyper‐V

Indicador Média Mínimo Maximo Avg. Disk Bytes/Read (KB/s) 12.144,909 8.174,345 27.146,039 Avg. Disk Bytes/Write (KB/s) 14.845,174 1.472,234 435.606,588 Avaliable Mbytes (MB) 562,288 442,000 608,000 Committed Bytes (MB) 4.486,352 4.347,726 4.638,465 Page Faults/Sec (ocorrência/s) 549,962 91,374 9.727,652 RPC Requests Outstanding (un) 2,150 0 23,000 RPC Averaged Latency (ms) 8,796 1,000 358,000 RPC Requests (un) 1,485 0 23,000 Local Delivery Rate (un) 0,377 0 3,600 % Idle Time 53,940 0 101,610 Current Disk Queue Length (un) 3,007 0 75,000 % Processor Time 8,503 5,078 50,000 % User Time 4,078 3,721 19,985 RTO (horas) 03h45

74

Tabela 4 ‐ Dados WPM e RTO: Oracle Virtual Box

Indicador Média Mínimo Maximo Avg. Disk Bytes/Read (KB/s) 0,021 0 0,126 Avg. Disk Bytes/Write (KB/s) 0,018 0 0,091 Avaliable Mbytes (MB) 793,747 694,000 966,000 Committed Bytes (MB) 7.345,594 7.345,594 7.345,594 Page Faults/Sec (ocorrência/s) 497,333 0 4.233,070 RPC Requests Outstanding (un) 0,396 0 6,000 RPC Averaged Latency (ms) 13,543 5,000 33,000 RPC Requests (un) 0,218 0 4,000 Local Delivery Rate (un) 0,363 0 3,416 % Idle Time 69,374 5,561 123,352 Current Disk Queue Length (un) 0,275 0 8,000 % Processor Time 42,341 0 94,231 % User Time 5,319 0 36,262 RTO (horas) Não coletado

Tabela 5 ‐ Dados WPM e RTO: VMware Server

Indicador Média Mínimo Maximo Avg. Disk Bytes/Read (KB/s) 0 0 0,039 Avg. Disk Bytes/Write (KB/s) 0,002 0,001 0,057 Avaliable Mbytes (MB) 460,149 374,000 597,000 Committed Bytes (MB) 3.881,118 3.815,846 3.949,584 Page Faults/Sec (ocorrência/s) 142,556 17,409 2.361,260 RPC Requests Outstanding (un) 1,778 0 7,000 RPC Averaged Latency (ms) 2,426 1,000 13,000 RPC Requests (un) 0,460 0 3,000 Local Delivery Rate (un) 0,366 0 3,594 % Idle Time 94,661 52,326 100,054 Current Disk Queue Length (un) 0,035 0 2,000 % Processor Time 99,871 95,626 100,000 % User Time 68,532 51,858 81,008 RTO (horas) Não coletado

3.3. DADOS COMPARATIVOS ENTRE OS AMBIENTES

Com os dados tabulados dos ambientes (3.2) foram gerados gráficos para

cada indicador utilizado, tendo como objetivo analisar o ganho em RTO dos

ambientes virtualizados em relação ao não virtualizado e em contrapartida verificar o

impacto causado pela virtualização no desempenho do ambiente.

75

Os gráficos gerados envolvem comparações entre o ambiente não

virtualizado e os hypervisores de tipo I, os dados dos hypervisores de tipo II (Oracle

Virtual Box e VMware Server) não foram relacionados para a análise comparativa,

pois o teste com o MELG não obteve sucesso fazendo com que os dados para este

tipo de hypervisor fossem excluídos das comparações.

3.3.1. Verificação do Tempo de Recuperação

Gráfico 3 ‐ RTO

Ao analisar o Gráfico 3 foi possível verificar que o tempo de recuperação dos

ambientes virtualizados é em media 40% inferior ao do ambiente não virtualizado,

proporcionando um ganho efetivo e diminuindo assim o tempo necessário para

restauração dos sistemas.

3.3.2. Disco (Físico e Lógico):

O desempenho do disco com os hypervisores do tipo I (Microsoft Hyper-V e

Citrix Xen Server) é equiparável ao desempenho obtido no ambiente não virtualizado

e em alguns casos superiores ao mesmo, por exemplo, na escrita em disco (Gráfico

5).

76

Gráfico 4 – Indicador (objeto) disco: Average Disk Bytes/Read

No processo de leitura em disco analisado através do indicador Average Disk

Bytes/Read (Gráfico 4) o desempenho da máquina física foi superior em 18% em

relação ao Microsoft Hyper-V e 12% superior ao Citrix Xen Server

Gráfico 5 ‐ Indicador (objeto) disco: Average Disk Bytes/Write

No indicador Average Disk Bytes/Write (Gráfico 5) que avalia o processo de

escrita em disco a máquina física teve pior desempenho com resultados inferiores

em relação ao Microsoft Hyper-V e Citrix Xen Server sendo 23% e 4%

respectivamente.

77

Gráfico 6 ‐ Indicador (objeto) disco: Current Disk Queue Length

Considerando o tamanho atual da fila no disco (leitura/escrita) com o

indicador Current Disk Queue Length (Gráfico 6), a máquina física teve desempenho

inferior (3 requisições pendentes) em relação ao Citrix Xen Server (2 requisições

pendentes) e em comparação ao Microsoft Hyper-V obteve praticamente o mesmo

resultado no momento da coleta dos dados.

Gráfico 7 ‐ Indicador (objeto) disco: % Idle Time

78

Os resultados do tempo de ociosidade do disco são proporcionais aos valores

do Gráfico 6, já que quanto maior o tamanho da fila, mais tempo o disco gastará

processando requisições e por consequência terá menos tempo de ociosidade.

No indicador % idle time (Gráfico 7) a máquina física permaneceu 70% do

tempo com o disco ocisoso (16 % inferior em relação ao Citrix Xen Server), o Citrix

Xen Server obteve melhor desempenho com 86%, e o Microsoft Hyper-V 54% (a

máquina física obteve resultado 16% superior).

3.3.3. Memória Devido aos requisitos de memória dos hypervisores diferentes quantidades de

memória foram alocadas para as máquinas virtuais, porem durante os testes

constatou-se que os hypervisores de tipo I utilizaram em média a mesma quantidade

de memória virtual (Gráfico 9) que a máquina física, já a memória física disponível

para uso imediato (Gráfico 8) pode ser considerada equivalente tendo em vista que

a memória extra da máquina física em relação aos hypervisores (aproximadamente

500 MB) não foi utilizada durante os testes com o MELG.

Destaca-se como desvantagem no Microsoft Hyper-V a ocorrência de muitas

falhas de página (Gráfico 10) acarretando em latência de acesso à memória e

ocasionando perda de desempenho no sistema

79

Gráfico 8 ‐ Indicador (objeto) memória: Available MBytes

Verificando a quantidade de memória disponível através do indicador

Available MBytes (Gráfico 8), pode-se constatar que a máquina física obteve melhor

desempenho em relação aos hypevisores de tipo I com 42 % a mais de memória

livre em relação ao Citrix Xen Server e 21% em relação ao Microsoft Hyper-V.

Gráfico 9 ‐ Indicador (objeto) memória: Commited Bytes

O indicador Commited Bytes (Gráfico 9), descreve a quantidade de memória

virtual em uso, o que permitiu analisar que tanto a máquina física quanto os

ambientes virtualizados apresentaram valores equivalentes (em média 4.5 GB de

80

memória virtual utilizada) sendo importante ressaltar que os hypervisores de tipo I

possuíam menor quantidade de memória física disponível e consequentemente

menor quantidade de memória virtual (1,5 vezes a memória física).

Gráfico 10 ‐ Indicador (objeto) memória: Page Faults / Sec

Com a análise do indicador Page Faults / Sec (Gráfico 10) pode-se constatar

que a máquina física apresentou melhor desempenho diminuindo a latência causada

por Page Faults, proporcionando 55% de superioridade em relação ao Microsoft

Hyper-V e 29% melhor em relação ao Citrix Xen Server

3.3.4. Processador

Neste quesito apesar do tempo ocupado em processamento dos hypervisores

do tipo I ser praticamente o dobro do que o da máquina física (Gráfico 11) no âmbito

global para o contexto avaliado não foi tão impactante, pois tanto para a máquina

física quanto para os hypervisores de tipo I obteve-se mais de 90% de ociosidade do

processador.

81

Gráfico 11 ‐ Indicador (objeto) processador: % Processor Time

O indicador % Processor Time (Gráfico 11) indica o tempo em que o

processador esteve ocupado. A máquina física obteve desempenho pouco superior

com aproximadamente 3% de utilização do processador e 97% de tempo ocioso, já

os hypervisores de tipo I apresentaram 8% de utilização e 92% de tempo ocioso, o

que demonstra a equivalência entre os ambientes com uma diferença não relevante.

Gráfico 12 ‐ Indicador (objeto) processador: % User Time

O indicador % User Time (Gráfico 12) indica o percentual de tempo gasto pelo

processador em modo usuário. A máquina física gastou aproximadamente 2% do

82

tempo que o processador esteve ocupado com processos de usuário, em seguida o

Microsft Hyper-V com 4% e o Citrix Xen Server com 6%. Novamente uma diferença

não muito relevante.

3.3.5. MS Exchange IS

O MS Exchange IS (Information Store) é o responsável pelo arquivamento em

disco das informações dos usuários. Para os clientes de e-mail não encontrarem

problemas de recusa ou indisponibilidade de acesso aos serviços do Exchange

Server os indicadores RPC Averaged Latency e RPC Requests devem ter valores

baixos fazendo com que não ocorra negação nas requisições dos clientes.

O desempenho dos hypervisores de tipo I e da máquina física não sofreu

nenhum tipo de gargalo evidenciando que a virtualização não impactou

substancialmente no desempenho do serviço.

Gráfico 13 ‐ Indicador (objeto) MS Excahnge IS: RPC Averaged Latency

O indicador RPC Averaged Latency (Gráfico 13) é utilizado para verificar a

latência média de chamadas RPC, para obter respostas em uma quantidade de

tempo razoável o mesmo deve ser inferior a 50 ms e para melhor desempenho

sempre abaixo de 25 ms (TECHNET). Tanto na máquina física quanto nos

hypervisores do tipo I o resultado obtido foi satisfatório, com uma pequena

83

superioridade da máquina física em relação ao Microsoft Hyper-V que obteve

latência de aproximadamente 9 ms, já o Citrix Xen Server apresentou desempenho

equivalente a máquina física com aproximadamente 3 ms.

Gráfico 14 ‐ Indicador (objeto) MS Exchange IS: RPC Requests

O indicador RPC Requests (Gráfico 14) indica a quantidade de solicitações

RPC no processo de armazenamento de informações. A máquina física obteve

desempenho similar ao hypervisor Microsoft Hyper-V com aproximadamente uma

solicitação e pouco inferior ao Citrix Xen Server que obteve valor abaixo de um.

Entretanto todos os ambientes tiveram desempenho aceitável e inferiores ao

máximo recomendado, onde valores em média devem ser abaixo de 70.(TECHNET)

3.3.6. MS Exchange IS Mailbox O indicador Local Delivey Rate mostra a quantidade de mensagens trocadas

no mesmo domínio durante a execução dos testes. Os testes executados utilizaram

as listas de distribuição geradas pelo MELG e foram efetuados no mesmo domínio

podendo obter a taxa média de entrega de mensagens entre as caixas postais. No

Gráfico 15 é possível verificar que a máquina física e o Microsoft Hyper-V tiveram o

mesmo desempenho e que o Citrix Xen Server obteve um desempenho superior a

ambos.

84

Gráfico 15 ‐ Indicador (objeto) MS Exchange IS Mailbox: Local Delivery Rate

85

CONCLUSÃO

Finalizado o processo de analise dos resultados obtidos nos ambientes

propostos neste trabalho de conclusão de curso, claramente pode-se observar que a

virtualização desempenhou um papel de grande relevância como ferramenta de

apoio ao plano de recuperação de desastres, diminuindo em 40% o tempo de

restauração (RTO) dos sistemas e recursos interrompidos no caso mais drástico

envolvendo a perda total dos dados. É interessante destacar que esta redução de

RTO pode ser ainda maior utilizando os recursos extras dos hypervisores

(geralmente pagos) que prometem valores próximos de 0% de indisponibilidade

(zero downtime).

Através da analise dos indicadores de performance como proposta de

verificação dos benefícios e possíveis perdas com a utilização da virtualização pode-

se concluir que ambas as ferramentas de tipo II (Oracle Virtual Box e VMware

Server) utilizadas durante as simulações de carga de trabalho apresentaram falhas

enenhuma delas obteve êxito (100% de execução do MELG), tornando este tipo de

hypervisor inapropriado para implementação em um ambiente de produção como

servidor de e-mail.

Em contrapartida os hypervisores de tipo I conseguiram executar

corretamente os testes com o MELG, e a partir dos dados analisados alguns dos

indicadores de performance apresentaram resultados superiores aos obtidos pela

máquina física e nos indicadores cujos resultados foram inferiores, estes não

impactaram o desempenho do servidor de e-mail ao ponto de inviabilizar a utilização

deste tipo de hypervisor.

O sucesso deste experimento está diretamente ligado ao processo de coleta

dos dados gerados devido a carga do MELG que permitiu testar a robustez e correto

funcionamento do servidor de e-mail Microsoft Exchange Server 2007

dimensionando cargas para 600 usuários em um dia de trabalho (10 horas).

86

Os indicadores de disco, processador e memória além é claro dos específicos

de um servidor de email permitiram analisar o correto funcionamento do servidor,

avaliando a taxa de entrega local, o número de solicitações RPC e a latência destas

solicitações.

Por fim é importante lembrar que apenas a virtualização não será suficiente

para uma correta implementação de um plano de recuperação de desastres, pois há

diversos outros fatores que englobam a estratégia de recuperação e como requisito

é necessário ter uma politica de backup eficiente e consolidada.

87

TRABALHOS FUTUROS

Tendo em vista que a virtualização contribuiu diretamente para o ganho de

RTO e a mesma está atualmente em alta e em franca expansão, pode-se ressaltar

diversos pontos para trabalhos futuros tais como:

Simular diversas cargas de trabalho com diferentes números de usuário

Utilizar servidores com hardware homologado (Intel Xeon, AMD Opteron,

IBM Power, etc) de forma a permitir teste com outros hypervisores

Utilizar-se de outros tipos de servidores (Web, Banco de Dados,

Aplicação, etc) e respectivos indicadores

Utilizar diferentes formas de armazenamento para armazenamento,

backup e recuperação (NAS, SAN e Fita) e qual o impacto causado com a

utilização das mesmas.

Simular testes com rede e diferentes larguras de banda

88

REFERÊNCIAS BIBLIOGRÁFICAS

BITTMAN, T. J.; DAWSON, P.; WEISS, G. J. Magic Quadrant for x86 Server Virtualization Infrastructure. Gartner RAS Core Research, , n. May, 2010.

BOWKER, M.; LALIBERTE, B. Storage Networking: Critical Enabler of Server Virtualization. The Enterprise Strategy Group, 2008.

CAIN, M. W. MarketScope for E-Mail Systems. Gartner RAS Core Research, 2010. Disponível em: <http://www.gartner.com/technology/media-products/reprints/microsoft/vol10/article19b/article19b.html>. Acesso em: 21/6/2011.

Citrix. Virtualization, Automation and Advanced Management for the Datacenter. 2010.

Citrix. Five reasons to choose Citrix XenServer. 2011.

COOPER, D. F.; GREY, S.; RAYMOND, G. Project risk management guidelines: managing risk in large projects and complex procurements. Wiley, 2005.

Gartner. Quarterly IT Forecast 2011. Disponível em: <http://www.gartner.com/technology/research/quarterly-it-forecast/>. Acesso em: 14/7/2011.

Hyper-V Maximum Supported Configurations. .Disponível em: <http://blogs.msdn.com/b/nickmac/archive/2008/07/04/hyper-v-rtm-maximum-supported-configurations.aspx>. Acesso em: 10/7/2011.

IBGE. Estatística do Cadastro Central de Empresas 2009. ,2009. IBGE.

Integração Microsoft Active Directory. .Disponível em: <http://theworldbit.wordpress.com/2010/03/24/tutorial-windows-server-active-directory/>. Acesso em: 10/7/2011.

KAHANE, Y.; NEUMANN, S.; TAPIERO, C. S. Computer backup pools, disaster recovery, and default risk. Communications of the ACM, v. 31, n. 1, p. 78-83, 1988. ACM. Disponível em: <http://portal.acm.org/citation.cfm?doid=35043.35050>. Acesso em: 21/3/2011.

KLIPPER, S. ISO/IEC 27005. Information Security Risk Management, v. 2008, p. 63–97, 2011. Springer. Disponível em: <http://www.springerlink.com/index/J7X2571313853386.pdf>. Acesso em: 17/7/2011.

LAUREANO, M. Máquinas Virtuais e Emuladores. Novatec Editora, 2006.

LAUREANO, M.; MAZIERO, C. A. Virtualização: Conceitos e aplicações em segurança. Minicursos do VIII Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais, p. 1–49, 2008. Disponível em:

89

<http://www.ppgia.pucpr.br/~maziero/lib/exe/fetch.php/research:2008-sbseg-mc.pdf>. Acesso em: 21/3/2011.

MARTIN, B. C. Disaster Recovery Plan Strategies and Processes. SANS Information Security Reading Room, 2002.

Microsoft. Exchange Load Generator. Disponível em: <http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=14060>. Acesso em: 21/6/2011.

Microsoft Corporation. .Disponível em: <http://www.microsoft.com/en-us/default.aspx>. Acesso em: 20/6/2011.

Microsoft Hyper-V Server. .Disponível em: <http://www.microsoft.com/brasil/servidores/hyper-v-server/default.mspx>. Acesso em: 10/7/2011.

Microsoft Hyper-V Server: System Requirements. .Disponível em: <http://www.microsoft.com/hyper-v-server/en/us/2008-system-requirements.aspx>. Acesso em: 10/7/2011.

Microsoft Virtual PC 2007 SP1 Guest OS. .Disponível em: <http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=24439>. Acesso em: 10/7/2011.

Microsoft Virtual Pc 2007. .Disponível em: <http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=24439#overview>. Acesso em: 5/7/2011.

NANDA, S.; CHIUEH, T. A survey of virtualization technologies. Science, v. 179, p. 1-42, 2005. Citeseer. Disponível em: <http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.74.371>. Acesso em: 21/3/2011.

Open Source Software Testing Tools. .Disponível em: <http://www.opensourcetesting.org/>. Acesso em: 20/6/2011.

Oracle. Whatʼs New: Oracle VM VirtualBox 3.2. 2010.

Oracle Vm Virtualbox. .Disponível em: <http://www.oracle.com/us/technologies/virtualization/oraclevm/061976.html>. Acesso em: 10/7/2011.

ROSENBLUM, M. The Reincarnation of Virtual Machines. Queue, v. 2, n. 5, p. 34, 2004. Disponível em: <http://portal.acm.org/citation.cfm?doid=1016998.1017000>. Acesso em: 21/3/2011.

SING, A. An Introduction to Virtualization. Disponível em: <http://www.kernelthread.com/publications/virtualization/>. Acesso em: 20/3/2011.

90

SNEDAKER, S. Business continuity & disaster recovery for IT professionals. Syngress Media Inc, 2007.

STONEBURNER, G.; GOGUEN, A.; FERINGA, A. Risk management guide for information technology systems: Recommendations of the national institute of standards and technology. NIST Special Publication, 2002.

TECHNET, M. Microsoft TechNet Libray. Disponível em: <http://technet.microsoft.com/en-us/library/default.aspx>. Acesso em: 21/6/2011.

TRINDADE, J. M. C. DE B. PLANO DE CONTINUIDADE DE NEGÓCIO DA SOCIEDADE INTERBANCÁRIA DE SERVIÇOS (SIBS) ESTUDO DE CASO NUMA PERSPECTIVA DE GESTÃO DE BENEFÍCIOS, 2008. INSTITUTO SUPERIOR DE CIÊNCIAS DO TRABALHO E DA EMPRESA.

VERAS, M. Virtualização: Componente Central do Datacenter. Brasport Livros e Multimídia Ltda, 2011.

VMware. Understanding Full Virtualization, Paravirtualization and Hardware Assist. ,2007.

VMware. Getting Started with ESXi Installable. ,2009.

VMware. VMware vSphere 4.1. 2011.

VMware. The Architecture of VMware ESXi. .

VMware Server Online Library. .Disponível em: <http://pubs.vmware.com/server1/wwhelp/wwhimpl/js/html/wwhelp.htm>. .

VMware Server. .Disponível em: <http://www.vmware.com/products/server/overview.html>. Acesso em: 10/7/2011.

WALLACE, M.; WEBBER, L. The disaster recovery handbook. American Management Association, 2004.

WEISS, G. J.; MARGEVICIUS, M. A.; DAWSON, P., with Thomas J. Bittman. Magic Quadrant for x86 Server Virtualization Infrastructure. Disponível em: <http://www.gartner.com/technology/media-products/reprints/vmware/213635.html>. Acesso em: 13/7/2011.

WEN, T. C. Componentes, preparação e revisão de Planos de Continuidade de Negócios. Notas de Aula de Políticas de Segurança e Plano de Continuidade de Negócios, 2011.

Windows Server 2008: Visão Geral das Edições. .Disponível em: <http://www.microsoft.com/windowsserver2008/pt/br/r2-editions-overview.aspx>. Acesso em: 10/7/2011.