Jail no FreeBSD: Os milagres e os desafios da Virtualização - Revista Infra Magazine 2

O FreeBSD é um sistema operacional nascido em dezembro de 1993, derivado do antigo BSD386. Com o evoluir de cada versão, diversas funcionalidades foram somadas, dentre elas pode-se citar:

• FreeBSD é um sistema operacional livre, do tipo Unix-Like e descendente do BSD, que por sua vez é outro sistema operacional UNIX, desenvolvido pela Universidade de Berkeley;

• Imensa quantidade de aplicações portadas de outros sistemas operacionais como Linux, NetBSD, OpenBSD, dentre outros (são mais de 26.000);

• Sistema de arquivos extremamente poderoso derivado do UFS (Unix File System) com Soft Updates (UFS2). O Soft Updates foi introduzido no FreeBSD por Marshall Kirk McKusick e possui diversas qualidades, dentre elas uma poderosa verificação de integridade do sistema de arquivos, sendo uma ótima alternativa ao sistema de arquivos journaling (veja a Nota DevMan 1). Além disto, em conjunto com os recursos contidos no UFS2, tem-se um bom tratamento de grandes volumes de dados e I/O de disco;

• Cuidado extremo com a compatibilidade dos fabricantes de hardware mais conhecidos, aprimorando os drivers para uma melhor comunicação com os hardwares específicamente desenvolvidos para servidores. Isso fornece uma segurança para quem usa o FreeBSD e aprimora a HAC (Hardware Access List/Lista de Hardwares Acessíveis);

• Apresenta segurança robusta com o filtro de pacotes PF (Packet Filter), originado do OpenBSD, um sistema operacional específico para a tarefa de Firewall;

• Possibilita o uso de QoS (Quality of Service), CARP (Common Address Redundancy Protocol), VLAN (Virtual Local Area Network) e link aggregation já integrados ao kernel do sistema operacional;

• Faz de forma simples o balanceamento de gateways com recursos incorporados ao kernel;

• Avaliando a licença BSD, observa-se flexibilidade para a composição de soluções comerciais. Um exemplo é o sistema operacional para firewall IPSO, desenvolvido pela Nokia para os equipamentos Check Point, baseando-se totalmente no FreeBSD. Esse, sem dúvida, é um exemplo comercial de sucesso usando FreeBSD.

Observando estas funcionalidades é simples entender os motivos que fazem com que diversas empresas façam uso do FreeBSD, dentre elas: Yahoo!, Apache, Pair Networks, Blue Mountain Arts, Google, Fotolog, Orkut, MySpace, YouTube, Second Life e muitas outras. Analisando este cenário no Brasil, a adoção do FreeBSD vem crescendo com o tempo, sendo usado em diversas entidades governamentais, universidades e empresas.

São diversos exemplos de sucesso que fazem uso do FreeBSD, e este artigo aborda uma dessas possibilidades com Jail, uma metodologia poderosa, muito usada no passado e que ainda faz sucesso dentre muitos gerentes de rede.

O que é Jail e quais seus benefícios?

Primeiro precisa-se saber que Jail é um conceito antigo, usado por todos os ambientes Unix, e Unix-Like (que nada mais são do que sistemas operacionais parecidos com o Unix), como uma alternativa segura de publicar uma aplicação para acesso externo, isolando-a do resto do sistema operacional. Entretanto, Jail no FreeBSD representa uma evolução desse conceito, isolando não só uma aplicação, mas um sistema operacional por completo, com pilhas TCP/IP individuais, áreas de memória e acessos a disco, representando uma opção para a virtualização de sistemas operacionais FreeBSD.

Este texto revela como compor um ambiente em Jail no FreeBSD usando exemplos práticos, e também analisa seu uso aplicado à computação em nuvem e outras opções para a virtualização de sistemas operacionais.

É comum confundir Jail com outra metodologia muito presente no passado do universo UNIX e ainda usada até hoje, conhecida como Chroot. Deve-se ter em mente que Chroot (Figura 1) e Jail (Figura 2) são metodologias diferentes, com aplicabilidades bem específicas. Nota-se que o Chroot cria um novo diretório raiz (diretório virtual) e limita a aplicação a este diretório. Todas as bibliotecas, áreas de disco e demais acessos devem estar dentro deste novo diretório raiz. Esse método ainda é usado por aplicações tradicionais como o BIND (Berkeley Internet Name Domain) para a resolução de DNS de forma mais segura, pois eleva e muito o nível de segurança, isolando o raio de ação no momento de um ataque.

Figura 1. Funcionamento do Chroot (diretórios, arquivos e bibliotecas).

Figura 2. Funcionamento do Jail (maior controle das áreas do sistema operacional).

Comparando o Jail com o Chroot, observa-se que o segundo não separa a pilha TCP/IP ou controla os acessos de forma tão rígida como o Jail. Quando se usa Jail, o kernel do sistema operacional individualiza as áreas de rede, memória, processos, usuários e arquivos. Além disso, existem variáveis de kernel específicas para controlar as atividades de um ambiente Jail. Cada Jail pode interagir com outros ambientes da mesma forma que um ambiente computacional tradicional, diferenciando-se pela maior segurança a ele aplicada. O Jail cria um verdadeiro container, o que abre um leque de possibilidades para um ambiente de produção, homologação ou desenvolvimento mais seguro usando como se fosse um clone do sistema operacional principal aplicado a outra atividade, com um novo endereço IP, pilha TCP/IP e área de memória.

Do ponto de visa da segurança, tanto o Chroot quanto o Jail criam áreas de maior isolamento e elaboram a proteção da aplicação separando o diretório visto pela aplicação do sistema operacional, criando o que pode ser visto como uma virtualização de diretórios. Se o ambiente for atacado com sucesso, o atacante verá uma área isolada, ficando com sua ação limitada. Todas as informações publicadas dentro desta área estarão isoladas do ambiente principal, sendo muitas destas informações irrelevantes para o funcionamento do Jail como os arquivos de senhas, por exemplo. Assim, visando elevar a proteção do ambiente principal, recomenda-se depositar informações não verdadeiras para confundir o atacante. Como os backups são baseados em áreas de diretórios, basta retornar uma cópia de um período antes do ataque para ter o ambiente funcional novamente e estudar os motivos que deixaram o sistema vulnerável.

A primeira versão de Jail foi introduzida no FreeBSD 5.1. Depois desta data diversas modificações foram realizadas e hoje se pode contar com funcionalidades como IPv6, múltiplos endereços IP e com ambientes contendo binários de 32bits em um sistema operacional host de 64bits. Nas seções seguintes será visto como é simples configurar e gerenciar um ambiente em Jail com o uso do FreeBSD.

Desvendando um ambiente em Jail no FreeBSD

Quando se trabalha com Jail no FreeBSD, faz-se uso de ferramentas inclusas no sistema operacional e de um kernel preparado para este tipo de operação, dispondo sempre de um manuseio muito simplificado. Pode-se dizer que em toda a operação observam-se quatro ferramentas (três aplicativos e um script): jexec, jls, jail e do script /etc/rc.d/jail. O primeiro entra na console do ambiente Jail, o segundo lista os ambientes existentes, o terceiro cria o Jail e o último prepara os ambientes Jail de forma automatizada após o boot do sistema host.

Quando um ambiente em Jail é criado, pode-se fazê-lo da forma simples (automatizada) ou da forma mais trabalhosa (manual). Se for desejada a construção de um ambiente da forma manual, todas as bibliotecas e diretórios necessários para o funcionamento da aplicação deverão ser instalados manualmente. Para isto, cada comportamento da aplicação (necessidade de bibliotecas, diretórios para depósito de arquivos de logs, diretórios para a leitura de arquivos de configuração, etc.) tem que ser mapeado. A esse mapeamento define-se como dependência. A verificação de bibliotecas necessárias pode ser simplificada com o comando ldd. Um exemplo clássico para se entender esse mapeamento pode ser visto com o arquivo binário do jogo Doom (Listagem 1).

Listagem 1. Verificando dependência de bibliotecas.

  # ldd linuxxdoom
  libXt.so.3 (DLL Jump 3.1) => /usr/X11/lib/libXt.so.3.1.0
  libX11.so.3 (DLL Jump 3.1) => /usr/X11/lib/libX11.so.3.1.0
  libc.so.4 (DLL Jump 4.5pl26) => /lib/libc.so.4.6.29
  # 

Observa-se que os diretórios /usr/X11/lib e /lib devem existir no ambiente em Jail e estas bibliotecas (libXt.so.3.1.0, libX11.so.3.1.0 e libc.so.4.6.29) devem ser copiadas neles exatamente no mesmo diretório. Sem dúvida que esse é um ponto extremamente trabalhoso para um processo manual, pois se pode encontrar uma aplicação que possui muitas dependências. Assim, o melhor caminho para criar o ambiente Jail é fazer a instalação do novo ambiente com o CD/DVD e, se necessário for, pode-se remover o que não é preciso (diretórios, arquivos, dispositivos de acesso, bibliotecas). Observa-se agora a Listagem 2, que inicia o processo de criação do Jail com a definição do diretório onde residirá toda a estrutura do mesmo.

Listagem 2. Criando diretório para o Jail.

  # mkdir –p /usr/jail/Jail_Exemplo1 

O parâmetro –p faz com que toda a árvore de diretório seja criada caso não exista. Foi usado o diretório “/usr” porque, por padrão, esse é o diretório que tem mais espaço livre, mas qualquer diretório pode servir como base de um Jail.

Para que o Jail funcione, precisa-se de mais um endereço IP (IP alias) na interface primária do FreeBSD, e isso pode ser feito via linha de comando ou de forma definitiva modificando o arquivo de inicialização. Assim, é necessário modificar o arquivo /etc/rc.conf colocando os IP alias necessários, conforme a Listagem 3.

Listagem 3. Criando o IP alias.

  ifconfig_rl0_alias0=”inet 10.10.10.120 netmask 255.255.255.0” 

Definidas as informações do alias, pode-se ativá-lo e reconfigurar o ambiente que fornecerá os acessos à rede local ou à Internet ao Jail (Listagem 4).

Listagem 4. Aplicando a nova configuração de rede.

  # sh /etc/netstart
  Devd already running? (pid=3001)
  rl0: flags=10289(UP,BROADCAST,RUNNING, SIMPLEX, MULTICAST, NEEDSGIANT> mtu 1500
       inet6 fe80::20c:29aa:feda:8449%rl0 prefixlen 64 scopeid 0x1
       inet 10.10.10.120 netmask 0xffffff00 broadcast 10.10.10.255 ether 00:0c:29:ab:84:49
  add net default: gateway 10.10.10.1
  Additional routing options:.
  # 

Assim, a interface física Realtek (rl0), previamente configurada com o endereço IP 10.10.10.120 e máscara 255.255.255.0 (24 bits), receberá mais um endereço para trabalho (10.10.10.120). Importante deixar claro que um alias pode ou não estar na mesma subnet do endereço primário.

Tendo os requisitos de diretório e endereço IP necessários para a operação do Jail, basta seguir com a instalação do sistema operacional. Aqui será utilizado um DVD da versão 8.0 (Listagem 5).

Listagem 5. Instalando o sistema operacional no Jail.

  # mkdir /mnt/dvdrom
  # mount –t cd9660 /dev/acd0 /mnt/dvdrom
  # cd /mnt/dvdrom/8.0-RELEASE/base
  # cat base.?? | tar --unlink -xpzf - -C /usr/jail/Jail_Exemplo1 

Tomando como base o aspecto segurança, é indicado fazer uso de pacotes previamente compilados (packages) ou compilar a aplicação e depois remover os diretórios produtos desta compilação (Listagem 6).

Listagem 6. Customizando a estrutura de file system do Jail.

  # mount_nullfs /usr/ports /usr/jail/Jail_Exemplo1
  # mount_nullfs /usr/src /usr/jail/Jail_Exemplo1 

Podem-se depositar no diretório do Jail todos os devices (dispositivos de acesso como a unidade de DVD ou partição do disco rígido) necessários ao seu funcionamento. Isto pode ser feito de forma simples com o uso do comando cp, de acordo com a Listagem 7.

Listagem 7. Criando a estrutura de dispositivos.

  # cp -R /dev/null /usr/jail/Jail_Exemplo1/dev
  # chmod 666 /usr/jail/Jail_Exemplo1/dev/null
  # cp -R /usr/jail/Jail_Exemplo1_web/dev
  # chmod 666 /usr/jail/Jail_Exemplo1/dev/zero 

Nunca devem ser usados devices que controlem o acesso ao disco ou o acesso direto aos inodes (veja a Nota DevMan 2), pois existem métodos de invasão específicos que possibilitam o acesso ao sistema host via inode. Desta forma, deve-se deixar somente o necessário, removendo compiladores, área para compilação de fontes e comandos não usados como tftp, ftp e telnet. Isto é válido não só para o ambiente em Jail, mas para servidores tradicionais.

Existem casos em que a aplicação existente no ambiente Jail requisita para o seu funcionamento o diretório /dev exatamente como o ambiente host. Nestes casos, é indicado fazer o que exibe a Listagem 8.

Listagem 8. Montando o diretório /dev do host.

  # mount -t devfs devfs /jail/Jail_Exemplo1_web/dev 

O próximo passo é criar manualmente o Jail (Listagem 9). Essa tarefa pode ser automatizada com o boot (iniciar) do sistema operacional host, e isto será visto em detalhes neste artigo.

Listagem 9. Criando o Jail.

  # jail /usr/jail/Jail_Exemplo1 servidor01.dominio.com.br 10.10.10.120 /bin/csh 

Na Listagem 9 pode-se ver que a aplicação Jail é usada com diversos parâmetros, onde o primeiro indica o caminho (Path) que contém a estrutura de diretórios, bibliotecas e programas necessários ao sistema operacional dentro do Jail. O segundo parâmetro é o FQDN (Fully Qualified Domain Name) do servidor, seguido de seu endereço IP (alias da interface, definido anteriormente) e o ambiente shell para gerenciamento em linha de comando.

Como boa prática, é indicada a criação dos arquivos /etc/fstab (arquivo vazio) e /etc/resolv.conf dentro do ambiente Jail. Isso é necessário para um melhor funcionamento de aplicações que podem ser necessárias dentro do Jail.

Até o momento foi apresentado como criar manualmente um ambiente em Jail, mas pode-se automatizar este processo fazendo uso do script /etc/rc.d/jail. Para isso, é necessário inserir todas as informações necessárias no arquivo /etc/rc.conf (Listagem 10).

Listagem 10. Automatização do Jail no processo de boot.

  # Deseja ativar o uso de Jails?
  jail_enable="YES"
  #
  # Qual o nome do jail que será criado?
  jail_list="servidor01"
  #
  # Decida se o jail trabalha somente com o protocolo TCP/IP
  jail_socket_unixiproute_only="YES"
  #
  # O usuário root no jail pode mudar o nome do ambiente?
  jail_set_hostname_allow="NO"
  #
  # Vai montar o devfs no ambiente Jail?
  jail_servidor01_devfs_enable="YES"
  #
  # Vai montar o fdescfs no ambiente Jail?
  jail_servidor01_fdescfs_enable="NO"
  #
  # Decida se vai permitir o uso de SystemV IPC
  jail_sysvipc_allow="NO"
  #
  # Será montado o procfs no ambiente Jail?
  jail_servidor01_procfs_enable="YES"
  #
  # Qual será o hostname no ambiente Jail?
  jail_servidor01_hostname="servidor01.dominio.com.br"
  #
  # Qual será o diretório root do Jail?
  jail_servidor01_rootdir="/usr/jail/Jail_Exemplo1"
  #
  # Qual será o endereço IP?
  jail_servidor01_ip="10.10.10.120"
  #
  # Podemos executar um script quando iniciar o ambiente Jail
  jail_servidor01_exec_start="/bin/sh /etc/rc"
  #
  # Podemos definir o comando para executar quando parar o ambiente Jail
  jail_servidor01_exec_stop="/bin/sh /etc/rc.shutdown"
  #
  # Permitirá montar e desmontar sistema de arquivos?
  jail_servidor01_mount_enable="NO" 

Com estas informações pode-se colocar o ambiente do Jail em funcionamento usando o script:

  # /etc/rc.d/jail start 

  # /etc/rc.d/jail stop 

As variáveis do kernel que gerenciam a segurança de um ambiente Jail podem ser verificadas com o comando sysctl:

  # sysctl –a | grep jail 

Na Listagem 11 é possível verificar como exibir os ambientes Jail que estão em funcionamento no host, através do comando jls.

Listagem 11. Exibindo os ambientes Jails em operação.

  # jls
  JID IP Address Hostname Path
  1 10.10.10.120 servidor01.dominio.com.br /usr/jail/Jail_Exemplo1 

Observa-se que este Jail tem a identificação (ID) 1 e as demais informações de IP, FQDN (Fully Qualified Domain Name) e diretório Path também são exibidas. Deste modo, pode-se entrar na console administrativa do Jail executando um ambiente shell desejado (csh), como exibido linha seguinte:

  # jexec 1 csh 

Dentro do ambiente Jail, podem-se fazer diversas atividades; dentre elas, parar suas operações sem fazer uso do script /etc/rc.d/jail, bastando usar o comando kill:

  # jexec 1 csh
  # kill –KILL 1 

Como o Jail isola o novo sistema operacional em uma área completamente diferente, pode-se, com isso, instalar aplicativos diretamente da console do ambiente Jail. Como exemplo, pode-se verificar a instalação do MySQL via packages previamente depositados no Jail (Listagem 12).

Listagem 12. Instalação do MySQL no Jail.

  # jexec 1 csh
  # pkg_add msql41-server
  # pkg_add mysql41-client 

Usando Jail na Nuvem

O termo computação em nuvem, ou cloud computing, não é um tema novo, mas ainda agita muito as rodas de discussão tecnológicas. Fazendo uma análise macro, pode-se notar que ele nada mais é do que a forma mais completa de virtualização de um ambiente.

Observa-se que o desenho da nuvem é composto por um ou mais pools de servidores físicos equipados adequadamente com software de virtualização, compartilhando recursos como storage, switches, energia e meio físico no Data Center, fazendo uso de controle e gerenciamento centralizado.

Além disso, quando se imagina os sistemas operacionais sendo virtualizados neste ambiente, vê-se a possibilidade de poder usá-lo em qualquer um desses servidores físicos, melhorando o SLA (Service Level Agreement - Acordo de Nível de Serviço) do serviço entregue, como escalabilidade, versatilidade em duplicação de ambientes, failover, segurança, eficiência em uso de recursos de processador e memória, e com um melhor aproveitamento energético. Se isto tudo não for suficiente, ainda pode-se dizer que a virtualização, esteja ela compondo um ambiente em nuvem ou não, está contribuindo significantemente para a chamada Green IT, conservando recursos ambientais.

Computação em nuvens difere-se de diversos ambientes e não se pode confundi-la com a computação em grid, que é a combinação de computadores em cluster combinados para uma função em comum, compartilhando recursos como processamento e memória. Um exemplo clássico em banco de dados é o uso do Oracle RAC (Real Application Clusters), que fornece um cluster de vários nós Ativo-Ativo e compartilha memória RAM entre os nós do cluster.

Ainda pensando na computação em nuvem, pode-se dizer que existem diversos tipos, mas este artigo irá centrar os estudos em apenas três deles: pública (public) ou externa, privada (private) ou interna e híbrida (hybrid).

Para entender a diferença entre elas, imagine que na privada o compartilhamento de recursos é feito dentro de uma rede privada de dados específica para uma corporação, enquanto a pública é a forma mais tradicional, compartilhando recursos entre as corporações, com provisionamento dinâmico entre Data Centers. Já o modelo híbrido se posiciona como um modelo onde a corporação pode usufruir dos benefícios e estar tanto na pública quanto na privada.

Um conceito que ainda gera discussões é o uso de estruturas chamadas de interclouds (internuvens), onde se tem o relacionamento entre nuvens destinadas a diferentes organizações ou uma interconexão global de nuvens posicionadas em locais diferentes do planeta. Com isso, as corporações podem ter um nível de interação maior ou até ativar/transferir recursos de uma nuvem para a outra.

A pergunta que se deve ter em mente é: será que computação em nuvem é tão boa assim? Será que se aplica a todos os casos ou existem limitações? Onde se podem ter problemas inviabilizando o uso da computação em nuvem? A resposta é simples, onde existem normativos internos das corporações deixando claro o não trânsito de informações inerentes à corporação entre Data Centers ou onde existe a proibição de estruturas virtualizadas. Para os casos onde são exigidos componentes dedicados, basta projetar servidores específicos para o uso somente da organização em questão. O fato é que diversas qualidades e facilidades podem ser encontradas no que prega a computação em nuvem. Ela é uma tendência irreversível, e as empresas têm que se adaptar a ela.

Agora que já foi definido o que é a computação em nuvem, pode-se aplicar esse conhecimento para a tecnologia de virtualização de Jails com FreeBSD. Para isso, será referenciado o modelo de uma nuvem privada (private cloud computing) em um grupo de servidores físicos executando um software para a virtualização de sistemas operacionais como o VMware, Hyper-V, VirtualBox e Xen, por exemplo. Nesta estrutura serão instalados três servidores FreeBSD 8.1 chamados de Marte, Jupiter e Saturno (Figura 3).

Figura 3. Instalando o FreeBSD na private cloud computing.

Podem-se criar quantos Jails forem necessários, e para o nosso exemplo, serão configurados dois Jails no servidor Marte e um Jail no servidor Jupiter. Por fim, no servidor Saturno serão configurados mais dois Jails (Figura 4).

Figura 4. Configurando os ambientes em Jail.

Fazendo uma análise mais técnica, pode-se notar uma camada de virtualização, distribuída entre um pool de servidores formando uma computação em nuvem. Percebe-se que só estão sendo contratadas três máquinas, mas na verdade têm-se presentes oito servidores. Isso proporciona economia para o projeto na área de Data Center contratada e tira um melhor proveito do hardware físico usado para os servidores, sem falar que torna o projeto aderente a Green IT (TI Verde), outra tendência de mercado.

Comparações

O modelo de Jail do FreeBSD remete a fazer algumas comparações com conceitos aplicados em ambientes similares aos existentes em sistemas operacionais bem respeitados e conhecidos como o Solaris/Open Solaris, AIX e os próprios IBM Mainframes.

Buscando os registros históricos, vê-se que todo o processo de virtualização se iniciou com os mainframes, pois eram máquinas (e ainda são) muito caras, e precisava-se justificar de forma concreta sua compra para a aplicação de diversas tarefas. Assim, a IBM criou mecanismos para individualizar áreas dentro dos mainframes para serem criados diversos servidores com funções independentes. Tais áreas são chamadas de containers e podem ser encontradas nos atuais sistemas operacionais IBM System z (IBM z/OS) com o uso de virtualizações baseadas no hypervisor (IBM z/VM).

Analisando de forma simples, quando se usa virtualização, deseja-se reutilizar o hardware físico e compartilhá-lo com outros sistemas operacionais visando um aproveitamento máximo de recursos sem prejudicar o desempenho. Isto ocorre com diversas tecnologias que evoluíram, saindo do mundo mainframe e chegando até o universo Unix, para depois ser aplicada aos computadores Intel/AMD x86. São exemplos disto o VMware, Xen, Microsoft Hyper-V (Figura 5) e tantos outros.

Figura 5. Estrutura de um ambiente de virtualização.

O elemento responsável por exercitar a virtualização é chamado de Hypervisor e pode fazer ou não o papel de um sistema operacional equipado com as ferramentas necessárias para aplicar a virtualização e, como tal, sofre impactos como qualquer sistema operacional (carga de processamento, elevação do volume de requisições a memória RAM, consultas a áreas do disco feitas com mais frequência, etc.). Da mesma forma, o Jail aplicado no FreeBSD sofrerá o mesmo tipo de impacto e, sem dúvida, em qualquer projeto essas questões devem e têm que ser consideradas para que o usuário final da aplicação não seja penalizado com lentidões ou perdas de desempenho.

Assim, como se resolve essa questão? Basta, para isso, adequar o projeto na fase de concepção aos requisitos de carga da aplicação e especificar o hardware mais adequado. O problema é quando não se sabe que carga é essa, tendo, nestes casos, que contar com bom senso e um NOC (Network Operations Center - Centro de Operações de Rede) muito bem treinado para monitorar e indicar pontos de gargalos para a área corporativa de SLM (Service Level Management). Uma área corporativa de SLM é um conceito bem discutido no ITIL (IT Infrastructure Library), e é um modo prático de se antever aos incidentes e problemas.

Retornando ao modelo de virtualização aplicado nos Mainframes IBM, que foi introduzido em 1967, com o z/VM hypervisor, vê-se que é um funcionamento um pouco diferente dos modelos aplicados em plataformas x86. Observa-se que existe também uma granularidade customizada para melhor aproveitamento dos recursos de memória, processador, storage e rede de dados. Isso possibilita a virtualização de uma infinidade de máquinas em um único equipamento, usufruindo de um hardware que fornece um SLA (Service Level Agreement) extremamente elevado, com diversos níveis de redundância e suporte avançado. Pensando ainda em fácil crescimento, é prática equipar o hardware com todos os elementos, como CPU, memória e licenciá-los conforme a necessidade de crescimento, assim, facilmente com um telefonema pode-se adicionar mais desempenho ao ambiente de forma simples e rápida.

Em 1989, este modelo de virtualização foi aprimorado com o advento da tecnologia LPAR (Logical Partitions – Partições Lógicas). O LPAR enquadra-se como um elemento de virtualização no nível do hardware e pode fornecer um elevado nível de abstração aliado a um grau de segurança aplicado a mais de 60 containers em um único equipamento.

Dessa forma, pode-se particionar uma máquina física em vários LPARs, cada um hospedando um sistema operacional distinto, compartilhando os mesmos recursos de hardware. A garantia deste compartilhamento é feita por um elemento chamado de PR/SM (Processor Resource/System Manager), que se integra com o IBM System z e representa para os ambientes IBM o hypervisor que é executado diretamente no nível do hardware.

Hoje LPARs podem ser encontrados em equipamentos não mainframe, como as máquinas IBM pSeries e IBM iSeries, criando múltiplas instâncias em um único hardware. Os LPARs permitem a segurança necessária para virtualizar bases de dados, um dos calcanhares de qualquer ambiente de virtualização, e acredita-se que só se estará livre desta problemática quando o próprio hypervisor – por software – garantir os IOPS (I/O por segundo) necessários para a validação deste projeto de virtualização.

Outro desafio que um ambiente virtualizado enfrenta é o licenciamento de alguns softwares, principalmente se o serviço é ofertado a terceiros. Para plataformas Microsoft isso tem que ser tratado com muito cuidado com seu gerente de parceria. Para bancos de dados, o que se deve ter em mente é se vai ser perdido o suporte contratado para o ambiente em questão ou se serão encontradas limitações para o atendimento, ou até se será garantido os IOPS (Input/Output Operations Per Second) desejados pelo projeto. Para softwares aplicados a ambientes ERP (Enterprise Resource Planning) ou SIGE (Sistemas Integrados de Gestão Empresarial) a necessidade é verificar se o mesmo está homologado para operar em ambiente de virtualização. Todos estes questionamentos devem ser feitos no início do projeto para que não sejam cometidos erros com impactos graves na precificação ou na própria invalidação da solução. A precificação é uma tarefa que deve ser feita na fase de projeto levando em conta todos os recursos necessários para o andamento do projeto.

Conclusão

Quando se pensa em Jail aplicado a um sistema equipado com FreeBSD, ou qualquer outra modalidade de virtualização, imagina-se um universo de possibilidades com áreas de memória distintas para cada Jail equipadas com portas TCP/IP e endereços IP exclusivos para cada área, além de uma poderosa ferramenta para virtualização de sistemas operacionais sob o mesmo ambiente do sistema host (hardware principal).

Isso se deve não só às bases sólidas herdadas do Jail existente em plataformas Sun Solaris, mas pela segurança, facilidade no manuseio e na configuração de um ambiente desse porte no FreeBSD.

Assim, sem nenhuma dúvida, se o sistema operacional usado for FreeBSD e se é desejada a composição de vários servidores FreeBSD, usando a mesma versão ou não da máquina host, a melhor opção é fazer uso do Jail, mesmo tendo opções mais amplas e mais poderosas como o VirtualBox. Mas falar de VirtualBox é outra história.