Boa noite pessoal.
Essa semana está um pouco corrida devido a um curso que estou fazendo sobre MDS, uma linha de switches da Cisco (mais para frente teremos mais este assunto :) ), mas vamos a mais uma parte do conteúdo sobre VMAX.
Vamos agora a parte 3 falando um pouco sobre a conectividade dos hosts com o VMAX e algumas coisas mais que sejam necessários e relevantes nesse quisito.
Basicamente, o VMAX é homologado para diferentes sistemas operacionais como HP-UX, AIX, Solaris, Linux, Windows, Virtual Machines e Hypervisors como ESX, XEN Server.
Para todos os hosts existe um documento da EMC de connectivity guide, onde são informadas as melhores configurações de parâmetros, tuning, multipath, dentre algumas best practices para conseguirmos usar todos os recursos do VMAX e não causar problemas na percepção do host e do usuário final quanto a performance e disponibilidade.
Devemos ter pelo menos duas portas de front-end do VMAX mapeadas para um host, sendo que estas portas não devem compor se possível o mesmo director, pois em caso de falhas não teremos redundância.
Abaixo, segue um desenho bem macro sobre a conexão de hosts para portar do VMAX:
Abaixo segue uma lista dos comandos para fazer scan SCSI Bus para reconhecer devices ou novos devices:
Solaris:
#devfsadm -C
IBM AIX:
>lsdev -Cc adapter -Fname |grep FC (comando para identificar os adapters HBA no AIX)
>cfgmgr -l fcs? (corresponde ao número do BUS adapter)
HP-UX:
$ioscan -fnC disk (scan e identificação de novos devices)
$insf -e (criação de volume para devices especiais)
Linux:
#echo " - - - " > /sys/class/fc_host/hostX/scan (sendo que o X corresponde ao número do BUS Adapter)
Windows:
C:\DISKPART
DISKPART> rescan
DISKPART> exit
Caso o mesmo servidor que vá receber um novo disco tenha instalado o Solutions Enabler, é possível fazer o rescan através do comando:
symcfg rescan
symntctl rescan (este apenas para Windows)
No caso de discos para ambientes virtuais, temos algumas formas para que isso seja feito. Na verdade uma coisa sempre será feita, que é zoning do host hypervisor na SAN para as portas de front-end do VMAX e por vez os discos apresentado para os WWNs do hypervisor ou dos hypervisors.
Este disco pode ser formatado pelo hypervisor e ser fatiado e assim entregue para as máquinas virtuais.
Todo o controle é feito na camada do hypervisor, referente a multipath, formatação, blocagem, alinhamento, etc.
Uma outra forma, é fazermos o mesmo processo de zoning, porém não formatar o disco na camada do hypervisor e mapear o disco diretamente para uma VM como RDM (raw device mapping). Seria o equivalente ao que fazemos com um host físico. Vale lembrar que hoje em dia já foi comprovado que apresentar um disco dessa forma tem praticamente a mesma eficiência a nível de performance do que um disco entregue e formatado pelo hypervisor. No entanto, isso ainda pode ser necessário por conta de algumas aplicações em específico como Oracle, Cluster dentre outros que precisam possuir um controle maior sobre esse disco diretamente e ver como esse disco é realmente, no modelo que ele foi criado no storage, como bloco, tipo, vendor, etc.
Exemplos de hypervisors suportados pelo VMAX:
Essa semana está um pouco corrida devido a um curso que estou fazendo sobre MDS, uma linha de switches da Cisco (mais para frente teremos mais este assunto :) ), mas vamos a mais uma parte do conteúdo sobre VMAX.
Vamos agora a parte 3 falando um pouco sobre a conectividade dos hosts com o VMAX e algumas coisas mais que sejam necessários e relevantes nesse quisito.
Basicamente, o VMAX é homologado para diferentes sistemas operacionais como HP-UX, AIX, Solaris, Linux, Windows, Virtual Machines e Hypervisors como ESX, XEN Server.
Para todos os hosts existe um documento da EMC de connectivity guide, onde são informadas as melhores configurações de parâmetros, tuning, multipath, dentre algumas best practices para conseguirmos usar todos os recursos do VMAX e não causar problemas na percepção do host e do usuário final quanto a performance e disponibilidade.
Devemos ter pelo menos duas portas de front-end do VMAX mapeadas para um host, sendo que estas portas não devem compor se possível o mesmo director, pois em caso de falhas não teremos redundância.
Abaixo, segue um desenho bem macro sobre a conexão de hosts para portar do VMAX:
Como podemos ver, cada host possui duas fibras indo para portas de front-end do VMAX, embora esta conexão esteja direto e sendo isso possível, não é recomendado. Dessa forma estaremos perdendo recursos de portas do VMAX, pois seria necessário na verdade, duas portas para cada host, onde três hosts iriam consumir 6 portas no total.
Essa comunicação é estabelecida através de uma SAN e processo de zoning. Dessa forma duas portas podem ser as mesmas para compartilhar recursos com estes três ou mais hosts.
Para diferentes tipos de hosts podem ser necessários bit flags configurados nas portas de FA, porém isso eu já comentei e para saber basta usar o connectivity guide dos hosts, lembrando que podemos fazer isso nos initiators group e não diretamente nas FA's, assim podemos fazer com que as FA's tratem caso-a-caso e não de forma global, sendo por atender determinados hosts e assim ser necessário criar mais port groups.
A tabela abaixo, mostra alguns exemplos de bit flags que são necessários para alguns hosts:
Solaris:
#devfsadm -C
IBM AIX:
>lsdev -Cc adapter -Fname |grep FC (comando para identificar os adapters HBA no AIX)
>cfgmgr -l fcs? (corresponde ao número do BUS adapter)
HP-UX:
$ioscan -fnC disk (scan e identificação de novos devices)
$insf -e (criação de volume para devices especiais)
Linux:
#echo " - - - " > /sys/class/fc_host/hostX/scan (sendo que o X corresponde ao número do BUS Adapter)
Windows:
C:\DISKPART
DISKPART> rescan
DISKPART> exit
Caso o mesmo servidor que vá receber um novo disco tenha instalado o Solutions Enabler, é possível fazer o rescan através do comando:
symcfg rescan
symntctl rescan (este apenas para Windows)
No caso de discos para ambientes virtuais, temos algumas formas para que isso seja feito. Na verdade uma coisa sempre será feita, que é zoning do host hypervisor na SAN para as portas de front-end do VMAX e por vez os discos apresentado para os WWNs do hypervisor ou dos hypervisors.
Este disco pode ser formatado pelo hypervisor e ser fatiado e assim entregue para as máquinas virtuais.
Todo o controle é feito na camada do hypervisor, referente a multipath, formatação, blocagem, alinhamento, etc.
Uma outra forma, é fazermos o mesmo processo de zoning, porém não formatar o disco na camada do hypervisor e mapear o disco diretamente para uma VM como RDM (raw device mapping). Seria o equivalente ao que fazemos com um host físico. Vale lembrar que hoje em dia já foi comprovado que apresentar um disco dessa forma tem praticamente a mesma eficiência a nível de performance do que um disco entregue e formatado pelo hypervisor. No entanto, isso ainda pode ser necessário por conta de algumas aplicações em específico como Oracle, Cluster dentre outros que precisam possuir um controle maior sobre esse disco diretamente e ver como esse disco é realmente, no modelo que ele foi criado no storage, como bloco, tipo, vendor, etc.
Exemplos de hypervisors suportados pelo VMAX:
O desenho abaixo mostra a abstração do que seria a conexão de um hypervisor com um storage array, tendo criado uma VM com um disco apresentado:
O disco neste exemplo é entregue pela camada do hypervisor, ou seja, está formatado pelo virtualizador.
Aqui podemos ver que o host VM continua recebendo os recursos do hypervisor, porém ele tem um disco que esta sendo entregue de forma "direta", passando apenas pelo hypervisor como uma ponte pela VM não possuir uma HBA atribuída.
Hoje temos a possibilidade de algumas vizualizações e administração de apresentação de discos para ambiente virtual, sejam feitas direto pelo Solution Enabler, porém é necessário passar o login de root e senha para o administrador de storage. O que pode não ser muito fácil de conseguir a nível de segurança dependendo do perfil da empresa.
Segue o comando para adicionar um hypervisor a administração do solutions enabler:
#symcfg auth -vmware add -host 192.168.0.123 -username root -password ******
Para verificar os hosts cadastrados:
#symcfg auth list -vmware
hostname Username Namespace Port
---------------------- ------------------------ ---------------------- -------------
192.168.0.122 root
192.168.0.123 root
#symvm list -server all
Server Name Type
---------------------------------------------------------------------
192.168.0.122 VMware
192.168.0.123 VMware
É possível através do Solution Enabler verificar quais são os servidores, hostname, sistema operacional e status de power on/off de um hypervisor:
#symvm list -server 192.168.0.122 -vm all
Podemos verificar os datastes:
#symvm list -server 192.168.0.122 -storage all
Para ver as informações específicas de um datastore:
#symvm show -server 192.168.0.122 -storage datastore_name
Verificando as informações de uma VM:
#symvm show -server 192.168.0.123 -vm LNX129
Adicionando um device RDM a uma VM pelo Solutions Enabler:
#symvm map -server 192.168.0.123 -vm LNX129 -array_id 0000129039401 -devs 386:387
O array_id deve ser o serial number completo do VMAX.
Comandos para fazer rescan em um ESX:
#esxcli storage core adapter rescan -all
#esxcli -s 192.168.0.122 -u root -p <password> storage core adapter rescan -all
Bem por hoje é só.
Com o tempo vocês irão ver que essa parte não é tão complicada. Alguns ambientes por serem mais sensíveis com certeza merecem alguma atenção e uma certa configuração de bit flags, como é o caso de clusters, banco de dados, Windows principalmente. No entanto, tudo configurado corretamente não tende a ser uma dor de cabeça para o administrador de storage, muito menos gargalo para o VMAX.
Algumas dicas que eu dou é de sempre lembrar aos sys admins de que deve ser configurado corretamente o multipath, sempre que possível encaminhar para estes times o PDF com o connectivity guide do respectivo SO, acompanhar e auxiliar nessa parte sempre que possível pois senão você sempre será acionado em caso de problemas de performance em disco, latência, erros de I/O enfim, quando recebem um problema de performance e vem que o disco vem de storage sempre existe um trabalho a quatro mãos.
Outra ferramenta que podemos utilizar para gerar uma matriz de compatibilidade entre host x storage é o E-lab no site da EMC.
Mais para frente irei fazer um post de como acessar e usar essa ferramenta do site da EMC que ajuda e muito. Provavelmente farei até um vídeo pois assim fica mais fácil de visualizar.
Bom pessoal, boa noite, fiquem com Deus e até a próxima!!! (quem sabe amanhã rsrs).
Abs!
Nenhum comentário:
Postar um comentário