Virtualizar o Recurso IBM DB2 pureScale no Linux Usando Máquina Virtual com Base em Kernel

Saiba como melhorar seu retorno sobre investimento ao implementar o Recurso IBM® DB2® pureScale® no Linux® em servidores IBM System x®. Os servidores System x modernos têm um amplo número de núcleos e quantidade de memória e recursos de E/S. Ao usar tecnologia de virtualização, é possível implementar diversas instâncias do DB2 pureScale em uma infraestrturua comum e obter maior eficiência.

Miso Cilimdzic, Senior Manager, DB2 Performance, IBM

Miso CilimdzicMiso trabalha na IBM desde 2000. Ao longo dos anos, ele trabalhou em diversos projetos, tendo como foco o DB2 nas áreas de desempenho, integração e exploração de hardware e design de sistemas otimizados para carga de trabalho. Atualmente, Miso gerencia a equipe DB2 Performance Benchmarking.



Peter Kokosielis, DB2 Performance and Virtualization, IBM

Peter KokosielisPeter é engenheiro de software no IBM Toronto Lab no Canadá. Ele faz parte da equipe de desempenho do DB2.



Mel Bakhshi, System Engineer, Performance Analyst, IBM

Mel BakhshiMel é engenheiro de software no IBM Toronto Lab no Canadá. Ele faz parte do Systems Optimization Competency Center, especializado em soluções otimizadas para carga de trabalho. Anteriormente, Mel trabalhou em um grupo de serviços de software especializado em desempenho do DB2 e do WebSphere Application Server.



14/Dez/2012

Introdução

O principal motivo para implementar a virtualização é maximizar a utilização de sua infraestrutura e melhorar o retorno sobre investimento (ROI). Ao usar tecnologia de virtualização, é possível compartilhar recursos de sistema, melhorando assim a utilização, densidade e economia de datacenter. Atualmente, os servidores IBM System x podem ser configurados com 16 núcleos em 2U de espaço em rack e 40 núcleos em 4U de espaço em rack. Isso significa que um cluster típico de três a quatro servidores pode oferecer de 48 a 160 núcleos em no mínimo 6U de espaço em rack.

A virtualização de instâncias IBM DB2 pureScale pode oferecer um ambiente isolado, porém consolidado, para sistemas de banco de dados de teste, QA e produção, pois permite que diversos clusters pureScale operem com o mesmo conjunto de recursos de hardware simultaneamente. KVM é um hypervisor Linux, implementado como módulo do kernel, que oferece a diversas máquinas virtuais (VMs) acesso simultâneo aos recursos de virtualização de hardware de processadores Intel. Usa QEMU (emulador de espaço do usuário) para emulação de hardware de E/S. Também pode ser gerenciado através da API libvirt e de ferramentas baseadas em UI. KVM entende as características de non-uniform memory architecture (NUMA) do CPU Intel e oferece à VM guest suporte para o adaptador de canal host (HCA) de remote direct memory access (RDMA).

Virtualizando dispositivos RDMA

Atualmente, é possível criar dispositivos, interruptores e redes Ethernet virtuais com KVM. No entanto, não existe a capacidade de criar dispositivos RDMA virtuais em um hypervisor. Para lidar com essa limitação, é possível usar passagem PCI. Em servidores System x, o hypervisor KVM oferece suporte para a conexão de dispositivos PCI no sistema host em guests virtualizados usando Intel Virtualization Technology for Directed I/O (VT-d). A passagem PCI permite que esses VMs guest tenham acesso exclusivo aos dispositivos PCI para diversas tarefas. Também permite que esses dispositivos PCI apareçam e comportem-se como se estivessem fisicamente conectados e como se fossem de propriedade do sistema operacional guest (SO). Com a passagem PCI, os VMs guests podem tornar-se proprietários dos adaptadores com RDMA que são usados em uma instância do DB2 pureScale.


Solução modelo para uma instância DB2 pureScale virtualizada

Abaixo você encontrará uma solução de modelo que explicará como configurar e implementar o recurso IBM DB2 pureScale em um ambiente virtualizado usando KVM. O modelo oferece um conjunto de configurações possíveis usando diferentes servidores IBM System x e explica a clonagem de VMs para implementar rapidamente mais instâncias do DB2 pureScale. Nós descrevemos a configuração e o desempenho de DB2 10.1 com o recurso pureScale sendo executado em VMs guest Red Hat Enterprise Linux 6.2 em um host Red Hat Enterprise Linux 6.2 com o hypervisor KVM. Siga as instruções abaixo para implementar as instâncias virtualizadas do DB2 pureScale em um hypervisor KVM.

  1. Selecione as opções de guest: hardware e software
  2. Planeje e configure a rede de área de armazenamento (SAN)
  3. Configure os componentes de KVM
  4. Crie e clone os guests KVM
  5. Implementar as instâncias do DB2 pureScale

Etapa 1. Selecione as opções do guest: hardware e software

As informações contidas na Tabela 1 mostra as possíveis opções de guest para virtualizar o recurso DB2 pureScale usando KVM em três servidores System x diferentes. Para a configuração de amostra é usado o servidor System x3850 X5, mas, para oferecer opções, as configurações de System x3650 M4 e System x3690 X5 também foram incluídas. Observe que o número de VMs guests para um dado servidor é uma função do número de slots PCI-E e do número de caminhos de Fibre Channel necessários. Para guests de produção, diversos caminhos redundantes de Fibre Channel são geralmente configurados, mas, para sistemas de teste e desenvolvimento, um único caminho de Fibre Channel pode ser suficiente.

Tablela 1. Virtualização do DB2 pureScale em servidores System x — opções de guest
Servidor System xGuests KVM (Fibre Channel de caminhos múltiplos*)Guests KVM (Fibre Channel de caminho único)Guests KVM (ao menos 1 Fibre Channel de caminhos múltiplos)Número máximo de slots PCI-E
x3650 M4
(2 soquetes)>
3** [0]4** [0]3 [1]6
x3690 X5
(2 soquetes)
2 [1]2 [1]2 [1]5
x3850 X5
(4 soquetes)
3 [1]4 [1]4 [1]7

* Usando Fibre Channel de porta dupla

** Usando o opcional Mezzanine de Ethernet 10 Gb

[ ] Slots de PCI que sobram

O número de opções de VM guest será um fator para determinar o número de instâncias DB2 pureScale. Usando a técnica de passagem de dispositivo e considerando que há um total de sete slots PCI-E Gen2 em um servidor x3850 com quatro soquetes, é possível criar três guests KVM, sendo que cada servidor físico terá esta configuração:

  • Três slots PCI-E Gen2 para InfiniBand */RDMA over Converged Ethernet (RoCE)
  • Três slots PCI-E Gen2 para Fibre Channel de porta dupla (duas portas por VM)
  • Um slot PCI-E Gen2 - pode ser Ethernet de 10 Gb de porta dupla

A localização e o layout de uma instância DB2 pureScale determina o número de instâncias virtualizadas. Por exemplo, com quatro servidores x3850 X5 de quatro soquetes, é possível ter até 12 VMs guests do KVM. Como mostra a Tabela 2, o número de instâncias do pureScale implementadas é determinado pelo número de dispositivos designados para cada VM guest e depende de estarem colocados em uma VM guest ou se têm sua própria VM guest dedicada.

Tablela 2. Número máximo de instâncias DB2 pureScale no x3850
Membro colocado/CF (2member/2CF)Membro/CF em VM dedicada (2member/2CF)Misto dedicado/colocado (2member/2CF)Membro colocado/CF (4member/2CF)Membro/CF em VM dedicada (4member/2CF)
Número máximo de instâncias do DB2 pureScale63532

Consulte a página de DB2 Virtualization Support para ver quais ambientes virtualizados são suportados. As opções de guests KVM do DB2 pureScale abaixo são o mínimo necessário:

  • Red Hat Enterprise Linux 6.2
  • Passagem de PCI para arquivos de sistemas GPFS
  • Interconexões RDMA

Etapa 2. Planejar e configurar a SAN

O layout de armazenamento da instância de DB2 pureScale requer alguns pré-requisitos e planejamento. É necessário configurar a conexão entre sistemas de armazenamento, comutadores SAN e hosts antes de configurar os discos. Para mais informações, consulte o Centro de Informações do Recurso DB2 pureScale. Por questão de simplicidade, recomendamos separar o armazenamento com a criação de grupos dedicados com mdisks, para que cada instância de armazenamento tenha seu próprio número da unidade lógica (LUNs). Quando os discos forem criados, usando o driver de caminhos múltiplos no Linux, os hosts podem ver todos os discos disponíveis. Os guests KVM poderão ver os discos quando os dispositivos Fibre Channel tiverem sido designados a eles. Para organizar o armazenamento, é necessário primeiro determinar o número de instâncias DB2 pureScale necessárias. Com base no número de instâncias, você irá configurar os discos de armazenamento compartilhados e desempatador. Para mais detalhes sobre a configuração de disco do DB2 pureScale, consulte o Centro de Informações DB2 pureScale.

Etapa 3. Configure os componentes do KVM

Pré-requisitos de hardware

O hardware deve ser capaz de virtualização Intel (VT-x) e VT-d. Processadores Intel Xeon classe X7560 ou superior são apropriados. O suporte à instrução de virtualização deve ser ativado nas configurações da BIOS. A designação de dispositivo PCI está disponível em plataformas de hardware que oferecem suporte para Intel VT-d. Consulte a página da web Enabling Intel VT-x Extensions in BIOS para mais informações.

Sistema host

Instale o sistema operacional Linux com o recurso KVM. Os pré-requisitos do sistema são os seguintes:

  • O parâmetro intel_iommu=on nos parâmetros de boot do kernel encontrados no arquivo /etc/grub.conf
  • Ao menos um adaptador InfiniBand* ou Ethernet 10 Gb (RDMA sobre Converged Ethernet) e uma porta Fibre Channel disponível por VM guest. Os adaptadores InfiniBand e Fibre Channel devem estar em seus próprios IRQ, sem compartilhá-lo com outros dispositivos no sistema. Observe que o KVM não pode iniciar um guest com um dispositivo de passagem PCI que esteja compartilhando um IRQ com outro dispositivo. Verifique a saída de lspci -v para ver se os dispositivos que você planeja passar para um guest KVM estão compartilhando um IRQ.

Ponte pública

Uma ponte de rede pública é necessário caso os guests KVM precisem de acesso à rede externa, incluindo comunicação com um cliente DB2 externo. Consulte a página da web Setting up a Network Bridge in the Host para mais informações. Antes de continuar, certifique-se de ter os pacotes RPM necessários, como bridge-utils, iproute e tunctl. Para esse tipo de tráfego externo, recomenda-se um adaptador Ethernet 10-GB com porta dupla, pois todas as VMs estarão compartilhando essa ponte e será necessário ter uma largura de banda ampla.

Etapa 4. Crie e clone os guests KVM

Antes de começar a criar os guests KVM e cloná-los, é importante confirmar se você tem a atualização mais recente do sistema operacional do host e do hardware de dispositivo. Consulte o Centro de Informações do DB2 para ver a lista de níveis suportados. Para criar e clonar as VMs guest, siga as instruções abaixo.

  1. Crie a VM guest

    Quando o sistema operacional host estiver instalado com os recursos do KVM, use o comando #/etc/init.d/libvirtd status para garantir que o KVM está em execução.

    Use o comando #/etc/init.d/libvirtd start caso seja necessário iniciar o KVM.

    O método mais intuitivo para criar uma VM guest é usar o programa gráfico virt-manager. Em preparação para esse tipo de instalação, você deve ter a mídia de instalação do Red Hat em formato de arquivo .iso em algum lugar do host. Para mais detalhes, consulte a página da web Creating Guests with virt-manager. Você usará as seguintes etapas de alto nível:

    1. Clique em Create a new virtual machine, edite o nome da VM (por exemplo, db2mVM1) e selecione Local install media. Em seguida, clique em Forward para continuar.
    2. Navegue até o arquivo .iso que contém a mídia de instalação do Red Hat, selecione o tipo do sistema operacional como Linux e escolha a versão correta. Clique em Forward para continuar.
    3. Selecione o número de CPUs e memória para essa VM. Clique em Forward para continuar.
    4. Crie um disco baseado em arquivo para armazenar a imagem de raiz do sistema operacional. Recomenda-se um mínimo de 10 GB. Dessa forma, é muito mais simples montar o dispositivo baseado em arquivo a partir de fora da VM, caso seja necessário fazer alterações em um arquivo no seu sistema de arquivos sem que a VM esteja em execução. Isso também proporciona flexibilidade caso você queira automatizar alguns procedimentos de clonagem no futuro. Mantenha o particionamento o mais simples possível, criando apenas uma partição. Clique em Forward para continuar.
    5. Selecione a configuração Advanced options e altere Virtual network de Default para Specify shared device name. Aparece um campo de entrada para o nome da ponte. Especifique a ponte pública aqui (por exemplo, pubBr0). Clique em Finish. Um console aparecerá, e você passará pelo procedimento de instalação de Red Hat da mesma forma que aconteceria em um sistema físico normal.

    Anote o local do arquivo de imagem de disco criado na Etapa 4 e do arquivo XML gerado por virt-manager. Ele geralmente está localizado em /etc/libvirt/qemu. Esses arquivos serão necessários para clonar as outras imagens de VM. Você deve agora ter uma VM guest com um sistema operacional instalado. O host também pode ver a VM guest. É possível usar a ferramenta da interface da linha de comandos virsh para gerenciar guests e o hypervisor. Consulte a página da web Managing Guests with virsh para mais detalhes.

  2. Confirme os pré-requisitos para os recursos DB2 pureScale

    É necessário configurar ao menos duas redes: Ethernet e uma rede de comunicação de alta velocidade. A rede de comunicação de alta velocidade deve ser uma rede InfiniBand* ou Ethernet de 10 GB, conforme especificado na página de pré-requisitos do centro de informações do DB2 pureScale para Linux. É importante observar que as configurações devem ser concluídas após a VM ter sido criada. Consulte a página da web Configuring Ethernet and High-speed Communication Network para mais detalhes. Para usar a VM guest em um ambiente do DB2 pureScale, os requisitos e pré-requisitos são os mesmos que se aplicam a um host físico. Para confirmar os pré-requisitos, consulte a página da web de DB2 pureScale Feature requirements. Os exemplos incluem configurar a memória bloqueada máxima como ilimitada, configurar rsh/ssh, desativar SELinux etc. Ao seguir todas as listas de verificação, a imagem estará pronta para a clonagem, o que tornará fácil replicar a mesma imagem.

  3. Clone as VMs guest com base na topologia de instância

    A clonagem de uma VM guest pode ser realizada com diferentes métodos. Para mais detalhes sobre a clonagem de imagens VM, consulte as melhores práticas do fornecedor. As etapas abaixo são usadas para clonar um VM guest.

    1. Certifique-se de que a VM de origem está configurada corretamente para uma implementação pureScale. Deve ter o nível de sistema operacional correto, os pacotes de RPM corretos instalados e as configurações corretas de acordo com os pré-requisitos do pureScale.
    2. Caso a VM de origem tenha dispositivos de passagem de PCI, é necessário removê-los antes de continuar com a clonagem.
    3. Faça uma cópia do disco de raiz do sistema operacional da VM (deve ser um arquivo no disco; use o comando virsh edit no guest e localize a tag source file= se não souber a localização do arquivo). Por exemplo, <source file='/home/dir/vm.img'/>. Altere o nome desse arquivo para o nome da nova imagem, por exemplo clone.img.
    4. Faça uma cópia do arquivo XML da primeira máquina virtual e altere o nome para o novo guest. Faça as alterações necessárias nesse arquivo XML. As alterações principais estão abaixo.
      • Nome da imagem — <name>newname</name>
      • Localização do novo arquivo de imagem — <source file='/home/dir/vm.img'/>
      • Endereço MAC da interface com ponte — <mac address='61:11:11:11:fe:9a'/>
    5. Com a nova imagem de disco e arquivo XML instalados, use o comando virsh define para construir o clone para a nova VM.
    6. Aplique as configurações de pós-instalação (como a configuração de rede) usando o console do guest.
    7. Adicione qualquer dispositivo PCI necessário para o guest de VM clonado. O método para isso é descrito a seguir.

    Repita as etapas acima para clonar os guests de VMs necessários. Após todos os guests de VM serem criados, defina os dispositivos PCI necessários para cada guest. Observe que cada guest precisará de ao menos um adaptador InfiniBand* ou RoCE e um adaptador ou porta Fibre Channel.

  4. Designe os dispositivos de hardware a todas as VMs guest

    Identifique o endereço PCI do dispositivo que você deseja passar para o guest, inclua a entrada apropriada para ele no arquivo de configuração XML e desconecte esse dispositivo do sistema host. Isso pode ser feito pelo virt-manager ou pela interface da linha de comandos. Usamos a linha de comandos para este exemplo.

    1. Identifique os dispositivos no host. Observe o número de pci-device à esquerda.
      # lspci | grep Mellanox
      04:00.0 InfiniBand: Mellanox Technologies MT26428......
    2. Confirme a existência do mesmo pci-number encontrado acima na lista de nós de dispositivos, usando virsh nodedev-list --tree . Você deve encontrar pci_0000_04_00_0 na saída, que corresponde ao endereço 04:00.0.
    3. Mostre os atributos de PCI do dispositivo, examinando para isso o conteúdo do arquivo XML usando # virsh nodedev-dumpxml pci_0000_04_00_0. Estamos interessados, em particular, nos valores de barramento, slot e função. É necessário converter esses valores para hexadecimal para gerar o XML apropriado na próxima etapa.
      # printf %x 4  	= 	4
      # printf %x 0 	= 	0
      # printf %x 0 	=	0

      Os valores a serem usados são:

      bus='0x4'
      slot='0x0'
      function='0x0'
    4. Edite o arquivo de configuração XML da VM guest e inclua os seguintes comandos para estabelecer a passagem VT-d PCI.
      # virsh edit db2mVM1
      <hostdev mode='subsystem' type='pci' managed='yes'>
      <source>
      <address domain='0x0000' bus='0x4' slot='0x0' function='0x0'/>
      </source>
      </hostdev>
    5. Remova o dispositivo PCI do sistema host.
      • Resolva o symlink:
        #readlink 	/sys/bus/pci/devices/0000\:04\:00.0/driver
        ../../../../bus/pci/dri	vers/mlx4_core
      • Remova o dispositivo do host:
        #virsh nodedev-dettach pci_0000_04_00_0
      • Verifique se ele tornou-se um stub de PCI:
        #readlink /sys/bus/pci/devices/0000\:04\:00.0/driver
        ../../../../bus/pci/drivers/pci-stub

    Repita as etapas acima para os dispositivos Fibre Channel. Observe que, ao designar o dispositivo Fibre Channel, você está designando apenas uma porta do adaptador, ao contrário de InfiniBand* ou RoCE, onde designa-se ambas as portas do dispositivo. Consulte a página da web Adding a PCI Device to a Virtualized Guest with virsh para mais detalhes.

    Reverter o processo de passagem de PCI é simples. O método recomendado é descrito abaixo.

    1. Use o comando virsh edit <domain name> e copie o XML que foi incluído para conectar o dispositivo PCI host e salve-o em um novo arquivo de texto em algum lugar. Isso é útil caso você queira conectar o dispositivo ao guest novamente no futuro.
    2. No editor virsh, exclua o XML que correspondente à conexão do dispositivo host e salve o arquivo XML.
    3. Use o comando virsh nodedev-reattach <pci address> para designar o dispositivo novamente ao host.
  5. Inicie as VMs guest

    Quando a designação de dispositivo for concluída, inicie a VM usando o comando virsh start db2mVM1.

    Se o comando tiver sucesso, aparecerá uma mensagem dizendo que a VM foi iniciada. Use o comando virsh list para mostrar qual VM está em execução atualmente.

    Se você puder ver a VM na lista, mas não puder fazer ping ou acessá-la, é possível que seja necessário configurar a rede. Para isso, acesse o console da VM através do virt-manager e faça as alterações de rede necessárias.

Etapa 5. Implemente as instâncias DB2 pureScale

O layout das instâncias do DB2 pureScale é determinado pelo número de guests de VM com pré-requisitos necessários. É possível criar diversas instâncias com base em InfiniBand * e RDMA sobre rede Ethernet. As instâncias são formadas por membros e recurso de acoplamento (CF). Com os dispositivos PCI-E designados às VMs guest, cada guest deve ter, no mínimo, um adaptador InfiniBand* ou RoCE e um adaptador ou porta Fibre Channel. Observe que todos os guests devem ter acesso ao armazenamento compartilhado. Consulte os detalhes sobre criação de instância na página da web DB2 pureScale Feature.


Configuração de amostra

Com base nas informações do modelo de solução acima, nosso exemplo usa três servidores System x3850, cada um com quatro soquetes e oito núcleos por soquete. Cada servidor físico tem sete slots de PCI. Com três servidores físicos, podemos criar 12 guests de KVM com seus próprios adaptadores dedicados com suporte a Fibre Channel e RDMA. Como mostra a Figura 1, com 12 guests do KVM, criamos quatro instâncias do DB2 pureScale. Duas das instâncias usam InfiniBand* e as outras duas, RoCE. Cada instância é formada por dois membros e um CF.

Figura 1. Infraestrutura de alto nível
Infraestrutura de alto nível

Hardware e software

Com base no layout mostrado na Figura 1, o hardware usado para configurar quatro instâncias do DB2 pureScale é mostrado na Tabela 3. Para as versões atualizadas e suportadas desses componentes, consulte o Centro de Informações do DB2.

Tablela 3. Configuração de hardware
Tipo de hardwareComponentes
Servidor IBM System x3850 X5 com 4 soquetes/ 32 núcleos e processadores Intel Xeon X7560 - 7 slots PCI-E Gen2
vendor_id : GenuineIntel
nome do modelo : Intel(R) Xeon(R) CPU X7560 @ 2.27GHz
cpu MHz : 1064.000
tamanho do cache : 24576 KB
núcleos de cpu : 8
sinalizadores : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm dca sse4_1 sse4_2 x2apic popcnt lahf_lm ida epb dts tpr_shadow vnmi flexpriority ept vpid
- 2 ConnectX VPI PCIe 2.0 5GT/s - InfiniBand* QDR / Ethernet de 10 Gb
- 2 ConnectX EN 10GbE, PCIe 2.0 5GT/s
- 2 Fibre Channel de 8 Gb para PCI Express HBA baseado em ISP2532
- 2 portas Ethernet de 1 Gb integradas
Comutador Mellanox IS5030 QDR InfiniBand*36 portas
IBM System Storage SAN40B-440 portas
IBM (BNT) Ethernet de 10 Gb - G8124 – RoCE24 portas
IBM Storwize® V7000- 18 HDDs SAS de 300 GB 10K RPM 2,5"
- 6 SSD SAS de 300 GB 2,5" (eML)

Com base nos ambientes de virtualização suportados pelo DB2 para arquiteturas x86 e x64, os níveis de software mostrados na Figura 4 são usados.

Tablela 4. Configuração de software mínima
SoftwareVersão*
Red Hat Enterprise Linux 6.2 — Host e Guest
  • 2.6.32-220.4.2.el6.x86_64 kernel
  • Para suporte a InfiniBand*, instale os pacotes de suporte a Infiniband.
  • Para RoCE, além dos pacotes InfiniBand, obtenha da Red Hat os pacotes de Rede de Alto Desempenho
Hypervisor KVM qemu-kvm-0.12.1.2-2.209.el6_2.4.x86_64
IBM DB2 com o recurso pureScale 10.1, FP1
Firmware Mellanox 2.9.1200

Armazenamento compartilhado

Para isolar o uso de disco pelas várias VMs no nível de armazenamento, o Mdisks e os conjuntos foram criados como mostram a Figura 2 e a Figura 3, respectivamente. Geralmente, o layout de disco e seu tamanho depende de fatores como o tamanho do banco de dados, atividades de log, etc.

Figura 2. Mdisks em conjuntos
Mdisks em conjuntos

Por questão de simplicidade, usamos apenas um disco compartilhado para conter a instância, banco de dados e dados de log, que residiram totalmente em unidades SSD. Para bancos de dados de produção, o layout pode ser diferente. Para ver a configuração de armazenamento recomendada, consulte o Centro de Informações do Recurso IBM DB2 pureScale.

Figura 3. Volumes designados a Mdisks
Volumes designados a Mdisks

Alocação de CPUs virtuais a guests de VM

Para o melhor desempenho e isolamento da carga de trabalho, a melhor prática é ter todo o conjunto de virtual CPUs (VCPUs) de uma VM preso a um conjunto de CPUs do host que reside no mesmo domínio de NUMA ou mesmo em um soquete de CPU. O comando lscpu informa o NUMA ou domínio de soquete de CPU aos quais pertencem os CPUs do host. Nós designamos VCPUs aos guests, como mostra a Figura 4. Um processo em execução no host pode ser executado em qualquer CPU. No entanto, o VCPU será sempre agendado em um CPU de host particular. Nós ajustamos o tamanho e número de nossas VMs de modo que o número total de VCPUs fosse igual ao número de CPUs físicas fornecidas pelo host. Como uma melhor prática, não alocamos mais VCPUs que CPUs de host porque comprometer recursos de CPU em excesso pode prejudicar o desempenho. Também nos certificamos de que o conjunto de VCPUs de cada VM fosse alocado ao mesmo domínio NUMA de host.

Figura 4. Alocação de CPUs virtuais para máquinas virtuais
Alocação de CPUs virtuais para máquinas virtuais

Medições de desempenho

A virtualização tem um impacto no desempenho. Para entender o impacto da virtualização em uma instância do DB2 pureScale, medimos o rendimento de uma carga de trabalho tipo OLTP usando instâncias de ambiente físico e virtualizado.

Para o servidor físico, criamos uma única instância do DB2 pureScale usando três servidores físicos, sendo que dois são designados como membros e um, como CF. Dado que cada servidor tem quatro soquetes com oito núcleos por soquete, desativamos três soquetes para manter o número de CPUs do host em 16 no mesmo nó NUMA e reduzimos a memória para 64 GB em cada servidor físico. Isso é para manter características semelhantes para ambientes físico e virtualizado.

A referência TPC-E simula a carga de trabalho OLTP de uma firma de corretagem. Usamos uma referência semelhante internamente para o ambiente DB2 pureScale. Os clientes remotos ativam a carga de trabalho para simular uma carga de trabalho tipo OLTP. A carga de trabalho é a mistura de leitura e gravação de 70 e 30, respectivamente. Cada execução gera diversos encadeamentos e o número de clientes para simular aplicativos do mundo real que acessam o banco de dados DB2 pureScale. Ao final de uma execução de sucesso, a referência produz vários relatórios, incluindo transações por segundo de cada execução. Após as medições do servidor físico terem sido coletadas, configuramos quatro instâncias virtuais com base na configuração de amostra descrita acima. As quatro instâncias virtualizadas do DB2 pureScale têm os mesmos núcleos de CPU, memória e sinalizadores de CPU que os servidores físicos.

Como mostra a Figura 5, as transações agregadas por segundo para duas instâncias virtuais em execução simultânea, mostra melhoria de 1,8 x no rendimento em relação a uma única instância virtualizada. Com base nas medições de rendimento, uma única instância virtualizada do DB2 pureScale usando passagem PCI tem 22% menos rendimento que uma instância em servidor físico. Algumas das principais características de desempenho do Linux, como a utilização de CPU e tempo de resposta do disco, refletem a perda de desempenho de 22%. Esse tipo de trocas é típico dos sistemas virtualizados, com base no que vimos no passado.

Figura 5. Rendimento agregado para instâncias virtualizadas
Rendimento agregado para instâncias virtualizadas

Conclusão

A virtualização do DB2 pureScale oferece uma maneira flexível de consolidar diversos aplicativos DB2 pureScale no mesmo hardware físico e permite maximizar a utilização desse hardware. Assim como a maioria das cargas de trabalho, a decisão de virtualizar ou não depende de um equilíbrio entre desempenho ideal e flexibilidade, utilização e custo. Com DB2 pureScale, é permitida apenas uma instância por sistema operacional, o que aumenta o valor dessa flexibilidade. Ao escolher virtualizar DB2 pureScale em Red Hat Enterprise Linux KVM, você terá os benefícios adicionais de isolamento de sistema operacional, isolamento de CF e isolamento de GPFS e disco, que não são possíveis hoje com qualquer outro método de multitenancy. A virtualização traz um melhor ROI de infraestrutura para seus servidores System x, e este artigo mostrou o modelo de solução e etapas detalhadas para virtualizar o recurso IBM DB2 pureScale em servidores System x.


Observação

* InfiniBand foi testado em um ambiente de laboratório, mas não é suportado para produção neste momento.

Recursos

Aprender

Obter produtos e tecnologias

Discutir

  • Participe da comunidade do My developerWorks. Entre em contato com outros usuários do developerWorks, enquanto explora os blogs, fóruns, grupos e wikis orientados ao desenvolvedor.

Comentários

developerWorks: Conecte-se

Los campos obligatorios están marcados con un asterisco (*).


Precisa de um ID IBM?
Esqueceu seu ID IBM?


Esqueceu sua senha?
Alterar sua senha

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


A primeira vez que você entrar no developerWorks, um perfil é criado para você. Informações no seu perfil (seu nome, país / região, e nome da empresa) é apresentado ao público e vai acompanhar qualquer conteúdo que você postar, a menos que você opte por esconder o nome da empresa. Você pode atualizar sua conta IBM a qualquer momento.

Todas as informações enviadas são seguras.

Elija su nombre para mostrar



Ao se conectar ao developerWorks pela primeira vez, é criado um perfil para você e é necessário selecionar um nome de exibição. O nome de exibição acompanhará o conteúdo que você postar no developerWorks.

Escolha um nome de exibição de 3 - 31 caracteres. Seu nome de exibição deve ser exclusivo na comunidade do developerWorks e não deve ser o seu endereço de email por motivo de privacidade.

Los campos obligatorios están marcados con un asterisco (*).

(Escolha um nome de exibição de 3 - 31 caracteres.)

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


Todas as informações enviadas são seguras.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=Linux, Information Management
ArticleID=851518
ArticleTitle=Virtualizar o Recurso IBM DB2 pureScale no Linux Usando Máquina Virtual com Base em Kernel
publish-date=12142012