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.

Advertisements

One response to “vCAP5-DCD – Dicas e Truques”

  1. Rogerio Chola says :

    Excelente Ale! Parabens!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: