vCAP5-DCD – Dicas e Truques

Antes de qualquer coisa, gostaria de agradecer a visita.

Sobre o exame, gostaria de ressaltar que realmente é um exame muito tenso, nem tanto pela complexidade das questões (e isso não significa que sejam “fáceis”), mas pelo tempo de prova, faz com que o candidato realmente sinta-se merecedor de um título tão importante. Em resumo são 100 questões, seis delas “Visio style” e as outras 94 de múltipla escolha e “drag-and-drop” a serem respondidas em 4 horas. Muitas das questões de “drag-and-drop” são tão complexas, e exigem tanta atenção quanto as “visio style”. O meu maior desafio foi manter uma média de 25 questões respondidas por hora. As questões vão avaliar conhecimentos gerais sobre desenvolvimento de soluções técnicas (visão, desenho lógico, desenho físico, mapeamento e entendimento de requirements, riscos, assumptions e constraints), conhecimentos gerais sobre Storage, Network, Security, e é claro, um profundo conhecimento da plataforma vSphere, seus componentes e suas funcionalidades.

É de fundamental importância para obter sucesso no exame estar alinhado com as melhores praticas recomendadas pela VMware, essas melhores praticas estão disponíveis na documentação indicada no Blueprint do exame (http://mylearn.vmware.com/mgrReg/plan.cfm?plan=30484&ui=www_cert) e também em uma grande variedade de livros sobre o assunto. Eu li alguns e gostaria de recomendar abaixo os que mais gostei (os quais julgo útil não somente como preparatório para o exame, mas também para aprimorar os conhecimentos para um dia-a-dia mais produtivo):

  • VMware vSphere Design (second edition)
  • Mastering VMware vSphere 5
  • VMware vSphere 5.1 Clustering Deepdive
  • VCAP5-DCD Official Cert Guide

Todos disponíveis aqui no Brasil, em livrarias que trabalham com livros importados, mas eu prefiro comprar lá fora, na Amazon por exemplo, por conta do preço.

Existem também muitos blogs gringos que dão dicas valiosas. Dentre eles, um grupo de estudos que publicou alguns vídeos bem interessantes no site http://professionalvmware.com/brownbags/. Alguns outros que referenciam artigos disponíveis na internet, os que mais gostei foram esses aqui:

http://www.elasticsky.co.uk/dcdguide

http://imallvirtual.com/?page_id=718

No linkedin existe um grupo de estudos o qual eu faço parte e chama-se “VMware Design Study & Discussion Group”, tem bastante material interessante sobre o exame disponibilizado por membros do grupo. Vale conferir e participar.

Seguem abaixo algumas observações relevantes que capturei em conjunto com um grande amigo e excelente profissional de virtualização, Daniel Lorenzato, durante a fase de estudos.

Se você tiver qualquer dúvida, observação, comentário, sugestão de dica ou tópico adicional ou correção que queira compartilhar… Deixe no campo de comentários. Certamente seus comentários serão muito bem vindos e levados em consideração. Eu quero muito ver esse post repleto de dicas, obviamente que cada uma delas referenciando o seu respectivo autor.

STORAGE

Vantagens / desvantagens boot from SAN:

Desvantagens

  • Adiciona dependência na camada de SAN
  • Aumenta a complexidade do Troubleshooting
  • HCL é menor para Boot from SAN
  • Implementação mais complexa

Vantagens

  • Servidores sem disco interno
  •      Podem ser mais compactos
  •      Podem dissipar menos calor
  •      Potencialmente mais baratos
  •      Substituição simplificada
  • Backup mais simplificado
  • Gerenciamento simplificado

Detalhes adicionais sobre Boot From SAN

  • Certificar de fazer o LUN Mask exclusivamente para o Host inerente (cada Host tem a sua LUN de boot)
  • DEVE ser configurado single-initiator zonning em cenários que usam Boot from SAN

Emuex e QLogic BIOS podem ficar sem resposta se vários outros initiators estão configurados no mesmo zonning (multiple-initiator zonning) e o cenário de Boot from SAN for implementado

  • Usar WWPN-based zonning ao invés de Port-Based zonning, usando Port-Based zonning, em uma eventual mudança de cabos para outra porta no Switch pode ocasionar problemas devido ao mecanismo de controle de acesso.

Questão sobre Initiators e Zonnings

  • Em um cenário onde Datastores são alocados em múltiplos Arrays diferentes conectados na mesma SAN Fabric, qual o tipo de zoning é recomendado?Segundo nota publicada no link abaixo, “Use single-initiator-single-target zoning when zoning ESXi hosts to Fibre Channel arrays. With this type of configuration, fabric related events that occur on one array do not impact other arrays.”

http://pubs.vmware.com/vsphere-55/index.jsp?topic=%2Fcom.vmware.vsphere.storage.doc%2FGUID-84821926-D4E5-40E7-800F-96A3C3F1DDA0.html

Passos para conectar o ESXi a um NFS NAS

  1. Criar um ou mais Portgroups para tráfego exclusivo de IP Storage
    1. É recomendado que se use redes dedicadas (uplinks dedicados / pSwitches dedicados) para o tráfego de IP Storage ou VLANs específicas para este propósito.
    2. NFS não usa mais que um uplink por target, portanto, para aumentar o throughput configure múltiplos portgroups usando dois ou mais uplinks e multiplos Targets.
    3. Se configurados múltiplos Portgroups, é recomendado que estejam em Subnets diferentes e com uplinks configurados como Active/Standby para tirar proveito do algoritmo de balanceamento de carga
    4. Client de NFS precisa estar ativo no Host (padrão)
    5. Mounting Point precisa estar configurado no Target
    6. É interessante usar um vSwitch dedicado para o tráfego de IP Storage caso os uplinks sejam dedicados para este propósito.
  2. Configure política de load balance e nic teaming para os port groups
    1. Para NIC Teaming pode-se usar Active/Standby para uma configuração mais estática ou Active/Active e deixar o algoritmo de Load Ballance trabalhar a distribuição do tráfego sem garantia de sucesso.
    2. Para Load Balancing podemos usar Route Based on IP Hash

Exemplos de melhores praticas:

 http://www.vmware.com/files/pdf/techpaper/VMware-NFS-BestPractices-WP-EN.pdf

NETWORKING

Load Based Teamming (LBT)

  • Load-Based teaming é a política de load balance recomendada pela VMware quando se possui no ambiente DvSwitches com NIOC habilitado.
  • Load-Based teaming somente disponível em DvSwitch.
  • Atua como a politica “Source Port Based Load Balancing” (Route based on the originating port ID, recomendado para Standard vSwitch).
  • Não requer qualquer configuração específica no Switch físico
  • Algoritmo balanceia automaticamente a carga nas interfaces de rede

The following features are available only on a dvSwitch:

  • Can shape inbound (RX ingress) traffic
  • Has a central unified management interface through vCenter
  • Supports PVLANs
  • Supports LACP for dynamic link aggregation configuration
  • Supports load-based NIC teaming
  • Uses persistent network statistics (sometimes referred to as network vMotion)
  • As of vSphere 5.1, the ability to import/export VDS configuration

Configurando alta disponibilidade para a rede de gerenciamento

das.isolationaddress[x] This option specifies that you now have more than one possible isolation address that should be available in the event of loss of network on one of the management ports. By default, with one management port, das.isolationaddress is set to the default gateway of the management port. Sample configuration for two isolation addresses

  • das.isolationaddress[0] 192.168.165.254
  • das.isolationaddress[1] 192.168.166.254

Importante! Esta configuração avançada também é útil quando o Default Gateway não é “pingável”, e nesta situação, um parâmetro adicional deve ser configurado das.usedefaultisolationaddress = false

das.failuredetectiontime This option defines the interval that triggers an HA failure if there is no network connection during that period. The default setting is 15,000 milliseconds.

In order to prevent the case of a false positive and having HA invoked because of an error, you should increase this to 30,000 ms:

das.failuredetectiontime 30000

Note: this setting is valid for vSphere 4.x environments, but not for vSphere 5.x environments. In vSphere 5.0, this setting has been removed and can’t be set. In vSphere 5.1, VMware added back a related setting called das.config.fdm.isolationPolicyDelaySec. This setting allows you to change the number of seconds before the isolation policy is executed; the minimum value is 30 seconds. In most cases, you won’t need to change this setting.

Beacon Probing

Entender o funcionamento do Beacon Probing (pra mim caiu um cenário “isio style” que em um dos requerimentos pedia um tratamento diferenciado da identificação de falhas de rede). O mais importante para não errar no desenho é saber que o Beacon Probing só funciona com 3 uplinks ou mais devido a um algoritmo de triangulação que ele usa para determinar falhas na rede (em CNA com apenas dois uplinks não é viável usar Beacon Probing). Mais um detalhe importante é que pode haver duplicação de pacotes se usado o Beacon Probing em conjunto com a vLAN 4095, portanto não é recomendado.

http://kb.vmware.com/selfservice/microsites/search.do?language=por_US&cmd=displayKC&externalId=2037196

Portas de Firewall

Não custa nada relembrar

  • 80
  • 443 – Client para vCenter / Client para Host / vCenter para Host
  • 902 – Host para Host / Client para VM (console)
  • 903 – Client para VM (console)
  • 1234/5 – vSphere Rplication
  • 2049 – NFS
  • 3260 – iSCSI
  • 5988/9 – CIM (Common Information Model)
  • 8000 – vMotion
  • 8100/8200 – FT
  • 8182 – HA
  • 636 – Linked Mode

DISASTER RECOVERY

Conceito das terminologias RTO / POR / MTPOD

O RPO e o RTO são fáceis de entender, pois são comuns no nosso dia-a-dia, já o MTPOD (Maximum Tolerable Period Of Downtime) é mais raro, mas não é coplicado. Em resumo, o RTO vai trazer os servidores e aplicações de volta online, depois disso, podem ser necessários mais alguns passos para que a operação volte ao seu nível de operação normal, esses passos adicionais podem não ser computados dentro do RTO e ai que entra o MTPOD. A figura abaixo ilustra a ideia.

http://www.bcmpedia.org/w/images/8/83/Recovery_Objectives_RTO_RPO_and_MTPD.png

 

PERFORMANCE

Entendimento dos contadores de performance do esxtop

Cenário relatando problemas de performance na VM vão necessitar da analise dos contadores, principalmente relacionados com CPU

http://www.yellow-bricks.com/esxtop/

Referencia: http://virtuallyhyper.com/2013/01/vcap5-dca-objective-6-2-troubleshoot-cpu-and-memory-performance/

Note que grande parte dos problemas é relacionado com vSMP ou limite de CPU (devido a configuração excessiva de CPUs por VM). Para corrigir esse problema, ou se remove processadores de algumas VMs ou adiciona mais Hosts no ambiente.

 

 

SEGURANÇA

Conflito de Permissões

Em um cenário onde um usuário não tem nenhuma permissão especifica em um objeto, porém faz parte de dois grupos os quais possuem permissões diferentes neste determinado objeto, a permissão efetiva desse usuário é a SOMA das permissões atribuídas a cada um dos grupos que ele faz parte (Esquece a regra de hierarquia de permissões da Microsoft, onde a  mais restritiva prevalece, aqui é a soma das duas que vale)

http://pubs.vmware.com/vsphere-4-esx-vcenter/index.jsp#managing_users_groups_roles_and_permissions/c_example_1_inheritance_of_multiple_permissions.html

Importante! A regra não se aplica caso o usuário ou grupo possua uma permissão explicita no objeto, as permissões explicitas (configuradas no objeto) sobrescrevem as herdadas.

GERENCIAMENTO

Ambientes geograficamente distribuídos

É importante conhecer as limitações para ambientes geograficamente distribuídos, a distância entre os dois sites pode inviabilizar o uso de metro vMotion devido a latência e também a replicação dos datastores em cenários onde se usa a solução de Stretched Cluster (também conhecida como vSphere Metro Storage Cluster – vMSC). Abaixo um artigo interessante sobre o assunto usando NetApp Metro Cluster.

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2031038

É importante saber que a solução de Stretched Cluster não substitui uma solução de Disaster Recovery usando SRM. SRM é uma solução de Disaster Recovery muito complexa que possui requisitos e características totalmente diferentes da solução de Stretched Cluster. Segue abaixo um artigo interessantes compara as duas soluções e suas aplicações.

http://www.vmware.com/files/pdf/techpaper/Stretched_Clusters_and_VMware_vCenter_Site_Recovery_Manage_USLTR_Regalix.pdf

Também é importante conhecer o recurso de Linked Mode, muito útil no gerenciamento de múltiplos sites.

http://pubs.vmware.com/vsphere-51/index.jsp#com.vmware.vsphere.install.doc/GUID-4394EA1C-0800-4A6A-ADBF-D35C41868C53.html

Abaixo algumas dicas de ferramentas de Script podem ser usadas para coletar informações (como healthcheck ou inventário, por exemplo) e automatizar rotinas administrativas no ambiente vSphere.

  • Perl + SDK
  • Power CLI
  • vSphere CLI

É importante saber o propósito de cada uma delas e também como usá-las, inclusive a partir de um appliance vMA (vSphere Management Assintant)

http://www.vmware.com/support/developer/vima/

Conceito de Downtream e Uptream

  • Downstream – Possui componentes dependentes, exemplo: SQL Server para Tomcat
  • Upstream – Dpende de outros componentes, exemplo: Tomcat para SQL

Conceito de ScaleUP e ScaleOUT

  • ScaleUP: Poucos servidores “parrudos” por cluster/datacenter
  • ScaleOUT: Muitos servidores “menos parrudos” por cluster/datacenter

Embora seja um conceito simples, é importante pensar sobre as vantagens e desvantagens de cada um desses approaches, no link abaixo tem um bom resumo. E o mais importante, ficar atento ao escopo dos cenários, muitas vezes o cenário não diz que quer usar ScaleUP ou OUT, ele diz que quer atingir o mais alto nível de consolidação possível para uma solução de VDI, dessa forma já se entende que estamos falando em ScaleUP, por exemplo.

http://www.vtagion.com/scalability-scale-up-scale-out-care/

Dica: Quando adotando o approache de ScaleOut usando Blade Servers, lembre-se que a Enclosure onde estão instalados os Blade Servers não pode ser um SPOF (considere a distribuição do ambiente em mais de uma Enclosure)

Teste de viabilidade de Downgrade de Servidor físico após a virtualização

Pode ser necessário, em alguns casos, justificar ou provar que o downgrade do servidor após o P2V não vai impactar a aplicação, uma forma de se fazer isso em Servidores Windows é configurando os parâmetros /maxmem (em MB) e /numproc (número de processadores) no arquivo boot.ini o que vai limitar o uso desses componentes pelo SO. Uma outra forma, mais “hardcore”, seria remover (fisicamente) o hardware do Servidor.

Advertisement

Propriamente endereçando arquivos de Swap em ambiente VMware

Não é raro hoje em dia se deparar com VMs com 16, 24, 32 GB de memória, e até mais em muitos casos. A virtualização esta se tornando cada dia mais confiável e sistemas críticos, que demandam alta utilização de recursos, estão sendo virtualizados. Se tratando de VMware, durante a fase de design/planejamento de novos ambientes (ou mesmo da criação de novas VMs) algumas pessoas esquecem que para cada VM existe um arquivo de swap que é criado com o tamanho fixo igual a memória configurada (menos a reserva) por padrão no mesmo local do arquivo de configuração da VM (“working irectory”) o que pode, em alguns casos, comprometer o espaço livre no Datastore (eu costumo usar o threshold de 20% de espaço livre em meus projetos). No final das contas, o arquiteto desenha a solução pensando em 20% de espaço livre, por exemplo, e quando implementado o projeto esses 20% baixaram para 15 ou menos dependendo da configuração das VMs (e quantidade de VMs por Datastore).

Eu pretendo com esse artigo auxiliar em algumas definições para evitar surpresas desagradáveis no decorrer da implementação do projeto.

A regra padrão é: sempre considere a existência do arquivo de Swap pondo na ponta do lápis a configuração de memória de cada VM quando dimensionando a camada de Storage. Eu costumo usar a seguinte fórmula para dimensionar a camada de Storage:

(“Soma dos VMDKs”+ (“Memória Configurada” – “Memória Reservada”))*1,2%

Essa fórmula me garante o espaço necessário para o arquivo de Swap e ainda me proporciona os 20% de espaço livre que eu costumo preservar no Datastore.

É possível armazenar o arquivo de Swap das VMs em locais diferentes do padrão (junto com o arquivo de configuração da VM), porém, alguns cuidados precisam ser tomados:

Quando alterado o local de armazenamento default do arquivo de Swap das VMs selecionando a opção “Datastore specified by host” em “Swap File Location” nas configurações do Cluster, este local alternativo deve ser configurado em cada um dos Hosts ESXi do Cluster. Supondo que um dos Hosts ESXi do Cluster não possua esse local alternativo configurado, se migrada uma VM para ele via vMotion o seu arquivo de Swap será criado no “working directory” da VM (local padrão).

É importante assegurar que o local alternativo possua espaço livre suficiente para acomodar os arquivos de Swap. Caso ao tentar ligar uma VM, não exista no local alternativo definido espaço livre suficiente para a criação do seu arquivo de Swap, o VMware tentará criá-lo no “working directory” da VM (não havendo espaço também no “working directory” a VM não ligará).

Não é recomendado armazenar arquivos de Swap em Datastores replicados, principalmente se a replica for síncrona. Assim como também é recomendado evitar o armazenamento de arquivos de Swap em Datastores que façam uso de tecnologia de Snapshot disponível em alguns Arrays (para evitar mal uso de espaço em disco).

Armazenamento do arquivo de Swap no disco local dos Hosts ESXi é uma alternativa viável para economizar espaço no Storage, entretanto, como o arquivo não esta em um Datastore compartilhado, quando necessário fazer um vMotion da VM para um outro Host ESXi o processo vai demorar um pouco mais visto que um novo arquivo de Swap será criado no disco local do Host ESXi de destino. O arquivo de Swap embora possua tamanho fixo, ele não é “zerado” em sua criação (o que torna o processo de criação desse arquivo mais rápido) e se o arquivo de Swap de origem possuir páginas de memória, essas páginas serão copiadas para o arquivo de destino.

Por fim, uma dica valiosa: Alguns Arrays possuem a capacidade de provisionar LUNs “Thin Provisioned”. Ou seja, o ESXi “enxerga” um tamanho de LUN que na verdade não esta totalmente disponível pelo Array, o qual “entrega” o espaço conforme a necessidade. Visto que o arquivo de Swap não é um arquivo “zerado”, em uma LUN “Thin Provisioned” se ele não possuir páginas de memória significa que ocupará muito pouco espaço (praticamente os metadados, apenas), o que viabiliza se devidamente controlado, uma utilização bastante eficiente do recuro de “Thin Provisioning” na camada do Storage. Mas eu vou reforçar aqui que este recurso precisa ser monitorado e devidamente controlado na camada de Storage para evitar problemas já que se o ESXi não interage com o mecanismo de “Thin Provisioning” do Storage, dessa forma, se o Storage diz para o ESXi que a LUN possui 1000 GB provisionados, o ESXi vai tentar usar esses 1000 GB.

Duvidas? Façam seus comentários, será um prazer ajudar.

Abraços e até o próximo post.

Introdução

Olá pessoal, gostaria de agradecer a visita e tentar passar a ideia principal desse blog.

Sou profissional da área de informatica, apaixonado por tecnologia e nos últimos anos venho me dedicando a virtualização. Eu acompanho uma série de “caras” muito bons que falam sobre virtualização na internet, todos eles publicam seus textos em inglês, e muito embora eu conheça muito bem o idioma inglês achei bacana postar minhas idéias em português, acredito que assim vou poder me expressar melhor e dessa forma transmitir de uma forma mais clara as minhas idéias, principalmente para o público que tem como nativo o mesmo idioma que o meu.

Quero postar aqui no blog textos relacionados com virtualização, dicas, novidades, guia de estudo para certificação, cursos e treinamentos, e assim por diante… Indo desde um nível mais básico até cenários mais complexos.

Espero que vocês gostem, contribuam com informações e deixem seus comentários, eles serão bem vindos.

Um abraço e até o próximo post.