Armazenamento no Hyper-V - TI Especialistas
O servidor de Hyper-V Pode utilizar praticamente qualquer tecnologia de armazenamento para suportar as maquinas virtuais. O dimensionamento de hardware é um pouco mais agressivo do que um projeto de um servidor de missão crítica, devido a natureza do ambiente virtualizado. Em um servidor físico que você terá uma aplicação crítica você terá apenas 1 workload para dimensionar o hardware. Entretanto em um servidor de virtualização você pode ter no mesmo hardware algumas maquinas virtuais que sejam bancos de dados, outras como servidores de arquivos, outros como servidores de correio eletrônico, etc. Cada um deles possui características e necessidades diferentes no que se refere ao uso de disco. Portanto dependendo do que você for virtualizar no mesmo hardware será necessário ter várias configurações de storage em uso simultâneo.
Para as maquinas virtuais o Hyper-V pode criar até 2 controladoras IDE (suportando até 4 dispositivos IDE) e até 4 controladoras SCSI (suportando um total de até 256 dispositivos conectados). Para utilizar a controladora SCSI virtual não é obrigatório a existência de uma controladora física SCSI no host (servidor de virtualização), pois isto é apenas uma representação de um dispositivo para a máquina virtual. Entretanto somente conseguem utilizar as controladoras virtuais SCSI os sistemas operacionais que suportam Enlightments, como Windows Server 2003 ou superior (as distribuições mais novas de Linux também conseguem utilizar os Enlightments). Para o boot do sistema operacional da máquina virtual é utilizado a controladora IDE virtual, e para os discos de dados você pode optar tanto pela controladora IDE virtual ou Controladora SCSI virtual. A diferença de uma para outra refere-se ao tipo de necessidade: se você precisa ter vários volumes virtuais na máquina virtual e/ou tenha necessidade de adicionar discos "a quente" (Hot Add) então utilize a controladora SCSI virtual. Em termos de desempenho há muita pouca diferença entre uma ou outra (apenas lembrando: não é possível usar o disco de BOOT do sistema operacional da máquina virtual em uma controladora SCSI virtual).
As opções mais comuns de utilização de storage para Hyper-V são:
O uso de iSCSI vem crescendo cada vez mais em todos os segmentos (pequenas, médias e grandes empresas). Entretanto vamos explorar este assunto em outros artigos, pois há grande dependência com serviços de rede.
Até o Windows Server 2008 R2 há restrições de uso do NAS como opção de storage para maquinas virtuais. Nem todos os cenários são suportados, entretanto você pode utilizar o NAS para armazenar os arquivos ISO, nas configurações de CD/DVD virtual. Isto não significa que não funcione, entretanto existe a grande diferença entre suportar e funcionar. Esta situação muda bastante no Windows Server 2012, pois a utilização do protocolo SMB 3.0 permite que os discos das maquinas virtuais estejam em um compartilhamento de rede, desde que o servidor de arquivos que terá os discos armazenados utilize o SMB 3.0 (o mesmo para o servidor de virtualização. O Windows 8 e o Windows Server 2012 implementam SMB 3.0).
As maquinas virtuais (VMs) podem utilizar as seguintes opções:
Esta opção permite mapear diretamente um volume/LUN de uma storage para a máquina virtual. Desta forma a criação de uma partição é feita pela máquina virtual. Isto significa que ela "escreve" em um disco/LUN sem o encapsulamento do VHD. Até o Windows Server 2008 esta era a opção que oferecia melhor performance. Entretanto a partir do Windows Server 2008 R2 seus índices de performance acabam se tornando muito próximos, e no Windows Server 2012 os índices de diferença são mínimos em relação ao uso de VHDs fixos.
Uma das desvantagens em relação ao uso do Pass-through Disk é a impossibilidade de realizar4 Snapshots (cópias em ponto de restauração), além de impedir que o mesmo volume seja utilizado para armazenar outras maquinas virtuais.
Caso crie maquinas virtuais baseadas em Windows 2000/2003 e opte por discos Pass-Through então tome muito cuidado com o alinhamento de disco. Por padrão partições criadas pelo Windows 2000/20003 não fazem alinhamento de disco (procedimento mnaul via DISKPART) e há casos (em especial bancos de dados) que a perda de performance nestes sistemas operacionais pode chegar a 40%. O Windows Server 2008 e o Windows Server 2008 R2 já fazem o Disk Alignment automaticamente e não há impactos quando são criadas maquinas virtuais que usem VHD e não fazem alinhamento de disco. Entretanto se você criar uma máquina virtual Windows 2000/2003 e usar Pass-Through é necessário fazer o alinhamento de disco, pois o gerenciamento da partição não será feito pelo host, mas sim pela máquina virtual. Por padrão o Cluster Size utilizado pelo Windows Server 2008 / R2 é de 1024k.
Disco fixo (Fixed VHD)
O VHD é uma estrutura que simboliza um volume para a máquina virtual. A ideia mais próxima de um arquivo VHD seria um ZIP, entretanto sem compactação. Quando o disco fixo VHD é criado o servidor de virtualização aloca automaticamente todo o tamanho no disco, não permitindo que o mesmo VHD seja fragmentado. Como o próprio nome diz, a princípio não é possível redimensionar o disco fixo VHD, mas caso tenha familiaridade com linha de comando então você pode usar o comando DISKPART e mudar este tamanho. Existem alguns utilitários de terceiros que fazem a mesma tarefa, e em destaque o mais conhecido é o VHD Resizer (http://vmtoolkit.com/files/default.aspx).
O uso do arquivo fixo VHD é recomendado para maquinas virtuais que tenham grande demanda de escrita/leitura em disco (em especial banco de dados, servidores de e-mail, servidores de arquivo/impressão, etc)
Se por exemplo você criar um arquivo VHD fixo com 127GB para uma VM, e a mesma ocupar apenas 20GB de dados então o arquivo VHD em questão terá 127GB. O arquivo não vai aumentar de tamanho, e no caso vai ocupar os 127GB, mesmo que você tenha apenas 20Gb de dados.
A estrutura do arquivo VHD também é utilizada para o disco dinâmico, com o diferencial do arquivo VHD crescer até atingir o tamanho estipulado durante sua criação.
Se por exemplo você criar um arquivo VHD dinâmico com 127GB para uma VM, e a mesma ocupar apenas 20GB de dados então o arquivo VHD em questão terá apenas 20GB. O arquivo pode crescer até 127GB, mas o tamanho do mesmo será apenas dos dados armazenados (no caso citado será 20GB).
O disco dinâmico pode sofrer fragmentação, pois durante sua criação o servidor não aloca os blocos em disco referentes ao tamanho total que o mesmo pode atingir. Este é um ponto de preocupação, pois
Utilize discos dinâmicos para fins de teste ou para maquinas virtuais que tenham pouca demanda de leitura/escrita em disco, ou então para cenários que precise economizar espaço em disco.
O VHD Resizer (http://vmtoolkit.com/files/default.aspx) também pode ser utilizado para converter discos dinâmicos para fixos.
Um ponto importante sobre o tamanho do arquivo VHD. No Windows Server 2008 R2 o arquivo VHD pode atingir até 2TB de tamanho. No Windows Server 2012 é possível criar tanto arquivos VHD quanto VHDX. Um dos diferenciais do VHDX no Windows Server 2012 é o suporte até 64TB de tamanho. Outro ponto interessante sobre o VHDX é sobre sua segurança: ao ser desligado abruptamente uma máquina virtual que utilize o VHDX então a possibilidade de corrupção de dados é mínima se comparado com o tradicional VHD.
Discos virtuais são susceptíveis a fragmentação, e é necessário executar o desfragmentador. Entretanto é importante entender que a fragmentação não ocorre apenas no nível NTFS, mas em 3 níveis:
Operações de escrita de blocos de dados em arquivos VHD são baseadas em FIFO (First-in, First-out). Como resultado os resultados se tornam fragmentados com o tempo. Discos VHD fixos possuem taxa menor de fragmentação, entretanto discos dinâmicos tem justamente o contrário. Executar o defrag de dentro da máquina virtual ajuda o sistema operacional da mesma a acessar de forma mais otimizada seus arquivos. Desfragmentar um arquivo VHD (ou "de fora da máquina virtual", no host) é necessário para discos dinâmicos, desde que os mesmos estejam desligados (não desfragmente um disco VHD dinâmico com a máquina virtual ligada pois o utilitário DEFRAG não é "Hypervisor Aware").
Se você precisar criar maquinas virtuais que tenham acesso intenso de leitura/escrita de disco (como banco de dados, servidores de arquivo, servidores de correio eletrônico, etc.) então prefira utilizar discos Pass-through ou VHD fixos. Entretanto isto não isenta a utilização do desfragmentador de dentro da máquina virtual para otimizar o acesso a dados.
Para discos pass-through é necessário realizar a desfragmentação de dentro da máquina virtual, pois o host (servidor de virtualização) não terá acesso a LUN/Volume que estiver sob pass-though.
Se você possui maquinas virtuais com grande carga de acesso a disco (como por exemplo bancos de dados) e necessitar de um volume extra para armazenar algum dado provavelmente vai precisar de um novo volume e não vai querer parar a máquina virtual para incluir o mesmo. O Hyper-V permite incluir discos a quente (Hott Add) em uma máquina virtual sem a necessidade de desligara mesma para efetuar tal procedimento. Isto é feito através da adição de um device pela controladora virtual SCSI, conforme imagem abaixo:
Entretanto vale lembrar que só é possível adicionar um disco virtual sem parada (Hott Add) na máquina virtual de acordo com o sistema operacional da mesma. Isto significa que a maquina virtual deve suportar os Enlightments e apenas as edições do Windows Server 2003 ou superior podem usufruir deste recurso.
Os novos recursos disponíveis no Windows Server 2012 permitem cenários de maior escalabilidade e desempenho.
Suporte à Virtual Fibre Channel
Até o Windows Server 2008 não era possível fazer o pass-through de uma HBA (Host Bus Adapter) para uma máquina virtual. Em cenários onde era necessário fazer um Failover Clustering entre maquinas virtuais somente seria possível via iSCSI (o acesso à storage ocorre via Ethernet). Com este recurso é possível ter uma HBA instalada no Host e de uso exclusivo e dedicado para uma máquina virtual.
Até 4 virtual Fibre Channels por máquina virtual.
Suporte nativo para discos 4-KB
Os discos convencionais utilizam setores de 512 bytes e isto traz limitações para discos com grandes volumes. O formato 4KB utiliza 4.096 bytes por setor, permitindo volumes de grande capacidade.
Até 64TB de tamanho para o Virtual Hard Disk
Por padrão o Windows Server 2012 cria discos VHDX que permitem crescer até 64TB, habilitando cenários de grandes volumes de dados usando discos virtuais. Além disso o VHDX utiliza um log interno usado para verificar a consistência da gravação e evitando corrupção de dados em caso de falhas. Pelo fato de atingir até 64TB é necessário uma otimização de I/O para suportar grandes volumes.
Quando se tem Storages de diferentes fabricantes torna-se um ponto de atenção a transferência de dados entre as mesmas, principalmente em cenários de copias de maquinas virtuais de um lugar para outro. Quando é feita uma cópia de um VHD (por exemplo) o processo de cópia é gerenciado pelo Host e isto pode causar maior processamento, uma vez que há um meio intermediário entre as storages. Caso as storages suportam ODX então este processo de cópia torna-se muito mais simples e rápido, uma vez que o Host apenas recebe uma sinalização da storage informando que a cópia foi executada. Todo o processo de transferência ocorrerá entre as storages sem a intervenção do Host.
Muitos fatores podem afetar o desempenho do disco virtual. Desde a parte física (configurações na controladora de disco, ajuste de caching, etc) até a parte lógica (atualização do drive de controladora, configuração da máquina virtual, etc) existem muitos pontos que tornam muito difícil definir qual é o principal deles. Imaginando que você queira apenas analisar qual formato de disco virtual deve utilizar no Hyper-V então pode ser mais fácil de tomar a decisão baseado no tipo de cenário.
Quando são realizados testes de desempenho de discos basicamente são feitos 4 testes:
64K Sequential read
Além disso talvez você queira comparar também os discos virtuais com configurações de Pass-through, e aí pode chegar em um resultado muito próximo a isto:
Os dados são referentes ao Hyper-V do Windows Server 2008 R2 , entretanto já servem para ajudar a dimensionar e planejar melhor seu servidor de virtualização. Se você estiver utilizando um servidor com uma storage siga as recomendações de ajuste de desempenho do fabricante. Cada fabricante possui configurações específicas para o servidor e para a storage, de acordo com o tipo de utilização, tamanho do volume, etc.
Uma recomendação muito boa que você deve seguir caso tenha uma Storage refere-se ao Cluster Size que utilizará na partição que alocar os discos virtuais. Cada fabricante de storage possui uma recomendação e você deve segui-la. Entretanto de forma geral o princípio é de utilizar grandes tamanhos de Cluster Size para volumes com alta taxa de escrita.
Uma das partes mais importantes do cálculo de performance do disco refere-se ao IOPS (Input/Output Operations per Second). Um post que vale muito a pena ler é do MVP Marcelo Sincic (O que é e como calcular IOPS (Exchange, SQL, SharePoint, etc) e você pode ler na integra todo o significado do IOPS e como calcular no link abaixo:
http://www.marcelosincic.com.br/blog/post/O-que-e-e-como-calcular-IOPS-(Exchange-SQL-SharePoint-etc).aspx
Quanto maior for o valor de IOPS melhor o desempenho do disco. Para exemplificar melhor esta proporção seguem dados abaixo (extraídos do WIKIPEDIA):
Disco 7.200 RPM SATA 3 Gb/s ~75-100 IOPS
Disco 15.000 RPM SAS ~175-210 IOPS
Disco SSD simples (primeira geração) SATA 3 Gb/s ~8.600 IOPS
Disco SSD SATA 6 Gb/s ~85.000 IOPS
Durante o Microsoft TechEd Europa 2012 foi feita uma demonstração ao público de IOPS de uma máquina virtual no Windows Server 2012, na seguinte configuração de hardware:
Servidor-padrão de indústria com 4 sockets de processador
80 Logical Processors (10 cores + SMT)
256 GB of physical memory
5 LSI HBA with 40 SSDs
Maquina virtual configurada com:
IOmeter (ferramenta utilizada para teste)
4k, Random IO, Queue Depth =32, 40 concurrent threads
A ferramenta mais utilizada para testes de IOPS, tanto para ambientes virtualizados quanto para demais servidores é o IOMETER (www.iometer.org). Você pode baixar gratuitamente a ferramenta e fazer os testes. Se você tiver um servidor recém-adquirido (e que não esteja em produção) tente fazer testes com o IOMETER para medir qual cenário é melhor para você. Uma mudança no tamanho do Cluster Size, uma atualização de driver da controladora de disco, etc. podem fazer muita diferença no desempenho do servidor.
Outra ferramenta importante que pode ser utilizada para testes de performance no servidor é o Performance Analysis of Logs (http://pal.codeplex.com). A ferramenta é gratuita e possui vários testes prontos para medir a performance do servidor, inclusive com suporte a relatórios em HTML.