Bem vindos – Felipe Roque

Sejam todos bem vindos! Me chamo Felipe Roque e possuo uma longa caminhada no mundo de tecnologia. Neste primeiro post a ideia é me apresentar e contar um pouco da minha jornada no mundo de TI!

Minha formação técnica começou no segundo grau técnico, onde me formei em eletrônica pelo COLTEC – Colégio Técnico da Universidade Federal de Minas Gerais. Esse curso foi um divisor de águas na minha vida profissional, mesmo antes de passar pela experiência do primeiro emprego formal, pois foi o lugar no qual descobri minha vocação para tecnologia. Depois me graduei em Engenharia de Telecomunicações e também em Sistemas de Informação.

Meu primeiro emprego (e estágio) foi na IBM do Brasil. Subsidiária da multinacional IBM (International Business Machines Corporation). Nem preciso dizer que a IBM conta com mais de 398.455 colaboradores em todo o mundo e assim, a IBM é a maior empresa da área de TI do globo. Existe todo um “glamour” em ser um ibmista (como os funcionários se auto intitulam) e respirar, literalmente, toda a história a qual essa empresa é responsável. Só tenho gratidão por minha passagem de 10 anos nessa grande empresa. Entrei aos 17 anos como estagiário e era responsável por manutenção em notebook e desktops internos. Logo passei a fazer atendimentos externos a clientes com contrato de suporte e fui evoluindo, passando por manutenção dos mais variados tipos de  equipamentos como PDVs (Impressoras fiscais), equipamentos bancários (máquina de autoatendimento, ATMs, impressoras autenticadoras, PABX). Fui evoluindo e passei a realizar atendimento a clientes enterprise no qual ficava de plantão e atendia grandes clientes com seus servidores e equipamentos de armazenamento de dados.

Nesta época que nasceu a paixão pela qual sou hoje especialista; equipamentos de armazenamento de dados. Até então, eu trabalhava em Belo Horizonte, minha cidade natal na qual fui contratado. Foi então que surgiu a oportunidade e fui convidado para mudar para São Paulo e trabalhar na sede da IBM no Brasil e integrar o time do HRC (Hardware Resolution Center). Nesse time éramos responsáveis pelo suporte de segundo e terceiro nível de todos equipamentos IBM de plataforma Intel, SAN e Storages Midrange de clientes de todo Brasil com contrato de suporte ativo. Realizávamos também a ponte com a engenharia em casos de problemas que necessitavam alguma correção de código ou bug. Sou eternamente grato por ter vivenciado essa experiencia, pelo aprendizado, pela formação do que sou hoje como profissional. Fiz vários treinamentos de desenvolvimento técnico e profissional, fui ao exterior várias vezes por motivo de especializações nos laboratórios de desenvolvimentos dos produtos, fui premiado e reconhecido por meu trabalho de diversas maneiras, trabalhei com pessoas espetaculares que foram exemplo, mentores e as quais procurei me espelhar, ou seja, apenas motivos de gratidão!

Achei interessante contar um pouco do início da minha história, para que outras pessoas que estão começando a carreira possam se encorajar a lutar por seus objetivos e nunca desistirem deles. A história não para por aí, foram apenas os 10 primeiros anos, mas para o post não ficar muito longo, vou fazer apenas um resumo do meu perfil profissional e dividir o resto em outro post contanto meu contato com o produtos VMware e o mundo da virtualização!

Resumindo (rsss) , tenho mais de 17 anos de experiência no mercado de TI, 12 deles em suporte e implementação de grandes projetos e soluções envolvendo arquitetura de SAN, soluções de armazenamento e proteção de dados, virtualização e hiper convergência. Reconhecido com diversas certificações IBM, Brocade, DellEMC e VMware. Tenho paixão por tecnologias de armazenamento e transporte de dados com experiência e conhecimento em várias plataformas e arquiteturas, incluindo as utilizadas em Cloud Computing, plataformas convergentes e hiper convergentes.

Também tenho experiência em ministrar treinamentos técnicos e mentoring, sendo por alguns anos, instrutor do IBM Training Center em Tutóia / SP.

Minhas especialidades:

– Soluções de HCI: DellEMC VxRAIL e VMware VSAN.

– Soluções VMware incluindo vSphere, SRM, vSAN and NSX.

– Soluções de Storage DellEMC includinfo VNX, UNITY, DataDomain, RecoverPoint, VPLEX e XtremIO.

– Virtualização de Data Center, SDDC, Computação em Nuvem, Redes, Stortage, Arquitetura SAN, Hi-End Computing Platform Solutions, Storage Architecture and Solutions, Treinamentos Técnicos, Consultoria, Servidores Blade, Computação Hiper Convergente

Espero de verdade que esse blog seja um espaço de contribuição, troca de informações, interação e que eu possa compartilhar e ajudar a comunidade de usuários com um pouco de minha experiência e vivência neste mundo o qual, a cada dia, aprendemos um pouco e sempre temos novidades! Espero conseguir cumprir o objetivo de difundir conhecimento de forma prática e didática! Fiquem à vontade para contribuições, críticas e sugestões! Mais uma vez, sejam bem vindos e vamos juntos nessa aventura!!!

Abraços,

Felipe Roque

Ciclo de alertas no vROPs

O vRealize Operations nos mostra diversos alarmes referentes ao ambiente. É comum abrir a ferramenta​​ e​​ encontrar +10000​​ de​​ alarmes gerados. Achei que seria uma boa ideia​​ explicar​​ aqui como eles são gerados, cancelados e deletados do ambiente​​ e quais parâmetros controlam essas ações. Ajustá-los​​ pode ajudar bastante a manter a ferramenta focada nos problemas reais do ambiente e evitar os falsos positivos!

Intervalo de​​ Coleta do vROPs

Antes de tudo, temos que entender o que é um ciclo de coleta do vROPs.​​ O vROPs possui um​​ ciclo de coleta de informações que por padrão é de 5 minutos. Então de 5 em 5 minutos ele coleta informações do vCenter.​​ Lembrando que essa​​ coleta (o ponto no gráfico) é uma média de 15 amostras de 20s do vCenter.​​ O Sunny Dua tem um post que explica direitinho essa conta! Confira​​ AQUI.

O valor padrão é adequado para a maior parte dos ambientes.​​ Se você o diminuir​​ irá consumir mais storage e processamento para processar os dados adicionais. Se você o aumentar, irá consumir menos storage e processamento. Na dúvida, não altere!​​ Você pode confirmar essa configuração​​ no caminho mostrado nas Figuras abaixo.​​ 

Alarmes​​ e​​ Sintomas​​ 

Um alarme no vROPs é definido por um ou mais sintomas. Para​​ o​​ alarme ser verdadeiro todas as condições impostas pelos sintomas devem ser verdadeiras.​​ Vamos​​ utilizar​​ o alarme “Virtual Machine CPU Usage is at 100% for an extended period of time”​​ nesse artigo para entender o​​ seu​​ comportamento. ​​ Esse alarme possui somente o sintoma​​ “Virtual Machine sustained​​ CPU Usage is 100%”​​ mostrado na Figura abaixo.

 

Para entender o alarme, temos que ver o que faz o sintoma ser verdadeiro. Para ver essa informação basta seguir o caminho mostrado na Figura abaixo.​​ 

Clique no ícone do lápis para abrir as configurações do sintoma. Irá abrir a tela mostrada na Figura abaixo.​​ Em 1 podemos ver qual métrica está sendo verificada pelo sintoma. Em 2 qual o limiar que está sendo utilizado para causar o sintoma. No caso desse sintoma​​ a condição​​ verificada é​​ a métrica CPU | Usage (%)​​ ser igual ou maior que 100%.​​ Mas ser igual ou​​ maior​​ que 100% ainda não torna o sintoma verdadeiro!​​ 

Wait Cycle e Cancel Cycle

Os alarmes e os sintomas​​ do vROPs possuem​​ duas configurações: o Wait Cycle e o Cancel Cycle.​​ No​​ alerta​​ essas configurações podem ser verificadas no​​ caminho mostrado na Figura abaixo.​​ E no sintoma no caminho mostrado nas Figuras​​ abaixo apontado pelo​​ número 3.

O Wait Cycle​​ informa​​ o​​ número de ciclos​​ no qual o​​ sintoma​​ deverá encontrar a condição verificada​​ para que​​ ele​​ seja​​ verdadeiro.​​ No nosso alarme exemplo, o sintoma​​ é​​ verdadeiro​​ quando a métrica CPU | Usage​​ (%) é igual ou maior que 100% por​​ 6 ciclos. Como cada ciclo é em um intervalo de 5 minutos, podemos dizer que a máquina virtual tem que estar com CPU 100% por 30 minutos para o sintoma​​ ser verdadeiro.​​ 

O Cancel Cycle é o contrário. Ele irá informar o número de ciclos que o sintoma tem que ser falso para que o​​ sintoma​​ seja cancelado.​​ No caso a métrica CPU Usage deverá ser menor que 100% por 6 ciclos para que o sintoma seja falso.

Com o​​ Wait Cycle e Cancel Cycle é possível customizar o quão sensível será a análise do vRealize Operations. Caso você queria um alarme mais sensível, basta diminuir o Wait Cycle. Quer um alarme mais conservador? Aumenta o Wait Cycle.​​ O mesmo vale para o Cancel Cycle.

Vocês devem ter visto que a configuração de Wait Cycle e Cancel Cycle pode ser feita tanto na configuração do​​ sintoma como​​ na configuração do alarme.​​ A melhor forma de controlar a sensitividade é configurando no sintoma.​​ 

Todos os alarmes possuem a configuração de Wait Cycle com o valor 1 para garantir que​​ o alarme será ativado​​ assim que todos os sintomas que formam o alarme forem verdadeiros.​​ No nosso exemplo, assim que o sintoma for verdadeiro, o alarme será ativado e irá aparecer na aba de Alarms com o status Active.

​​ Todos os alarmes​​ também possuem o Cancel Cycle com o valor 1 para garantir que o alarme será cancelado assim que todos os sintomas não forem mais verdadeiros.

Milhões de alarmes Inativos

Entendemos como os alarmes ficam ativos e como eles são cancelados. Após o alarme ser cancelado ele​​ aparecerá com status inativo​​ conforme​​ apontado na​​ Figura abaixo.

O problema é que você pode começar a ver diversos alarmes nesse estado aparecendo na sua aba de alarmes.​​ O vROPs irá guardar alarmes e sintomas cancelados por 45 dias após os mesmos serem cancelados (pelo Cancel Cycle ou manualmente por um usuário). Caso 45 dias seja demais para o seu ambiente, você pode mudar esse valor no caminho mostrado na Figura abaixo.​​ No meu vROPs​​ eu já havia alterado essa retenção para 2 dias​​ (um valor bem baixo só para eu testar que os alarmes inativos sumiam).​​ Qual valor utilizar vai depender das políticas de retenção de informação da sua empresa​​ 😊​​ 

​​ 

Espero que esse artigo facilite um pouco o entendimento dos alarmes do vROPs. Caso algo tenha ficado confuso ou você possua alguma dúvida não seja tímido, pode usar a sessão de comentários abaixo!

Dicas – Atualização de vCenter Server Appliance

Olá pessoal, tudo certo? Hoje eu gostaria de compartilhar com vocês alguns pontos a serem levados em consideração antes de atualizar um vCenter Server Appliance. São pontos que eu encontrei durante atualizações e achei que seria uma boa ideia listá-los aqui para quem sabe, poupar alguns passos de troubleshooting na sua janela de manutenção​​ 😊

Para referência: ​​ A maioria das atualizações foram da versão 6.0 para as versões 6.5 ou 6.7.

Vamos lá!

 

Pré-requisitos​​ básicos

 

Antes de dar as dicas vamos ter certeza que você já garantiu os pré-requisitos básicos para essa atualização. Você vai precisar de:

- 1 endereço IP temporário na rede de gerência.

- Uma máquina Windows com acesso a essa rede de gerência.

- Checar a interoperabilidade com outras soluções VMware no ambiente. Verifique​​ AQUI.

- Checar o caminho de upgrade. Verifique​​ AQUI.

- Checar compatibilidade com Plug-ins de terceiros instalados no vCenter.​​ (Caso tenha plugins que não são compatíveis, irão aparecer warnings no stage 2 do upgrade do vCenter)

- Checar se possui recurso no cluster (porque temporariamente teremos dois vCenters ligados no ambiente) e se possui espaço no datastore.​​ 

-​​ Possui Update Manager? Será necessário rodar um assistente de migração antes do Upgrade. Nas versões 6.5 e acima o Update Manager é embbeded no vCenter.​​ Esse assistente é o arquivo​​ VMware-Migration-Assistant​​ presente na pasta migration-assistant na ISO do vCenter.

-​​ Um backup atual do vCenter (snapshot traz paz de espírito, mas não é backup!!1!!1!)

 

Dicas​​ da Priscilla

 

Verificou todos os passos acima e viu que pode prosseguir com o upgrade no seu ambiente? Ótimo, vamos agora as dicas!

 

  • Verifique se a senha root do vCenter está expirada.​​ 

Caso esteja expirada, o upgrade irá falhar no Stage 1 com “A problem occurred while getting data from the source vCenter Server”.​​ Você pode fazer essa verificação na interface VAMI do vCenter (​​ https://[VCENTER_HOSTNAME]:5480​​ ).​​ Atualize a senha root do vCenter!

 

  • Verifique que o assistente de migração está rodando no Update Manager.​​ 

Caso não esteja​​ rodando,​​ o upgrade irá falhar no Stage 1​​ com a mensagem “Unable to retrieve the migration assistant extension on source vCenter Server.​​ Make sure migration assistant is running on the VUM server.”​​ Verifique novamente os pré-requisitos básicos!

 

 

  • Verifique se a interface de rede do vCenter está nomeada como eth0.​​ 

Caso esteja com outro nome o upgrade irá falhar no Stage 2 com “Internal error occurs during execution of upgrade process.”. A VMware já tem um artigo (KB2147933) com essa dica e de como resolvê-la. Confira​​ AQUI.

 

  • Verifique que o Update Manager está com Status GREEN.​​ 

Caso o update manager não esteja com o status green o upgrade irá falhar no Stage 2 com “VMware​​ Update manager health status is red”. No meu caso, um restart do serviço Update Manager no Windows resolveu​​ o problema.

 

  • Verifique a versão dos switches distribuídos.​​ 

As vezes a atualização do vCenter e dos hosts é realizada, mas os switches distribuídos ficam para trás. Confirme que os switches distribuídos estão em uma versão compatível com a versão de upgrade do vCenter.

 

  • Verifique se​​ o arquivo EAM.PROPERTIES está corretamente preenchido.

Caso não esteja preenchido corretamente, o upgrade irá falhar no Stage 2 com “Error: Internal error occurs during vSphere ESX Agent Manager pre-upgrade checks.” Dê uma olhada nos passos do KB 50113982 (link​​ AQUI) para corrigir esse erro!

 

  • Verifique o tamanho da partição / do vCenter.​​ 

No final do Stage​​ 2, o​​ Wizard de upgrade​​ poderá​​ avisar que não há espaço o suficiente na partição /​​ para realizar o Upgrade e pedirá um diretório para realizar a exportação de dados excedentes​​ (A imagem abaixo destaca esse aviso). Caso esse aviso apareça para você, realize o procedimento descrito no artigo KB 2113947​​ (Link​​ AQUI).​​ Ao finalizar o procedimento, basta inserir o caminho no Export Directory (no caso do KB o aminho criado foi /storage/tmp2)​​ e concluir o Wizard.

 

  • Erro ao realizar o dump do banco postgres do vCenter. Esse erro aparece no Stage 2 quando o Wizard está gerando o dump do banco do vCenter original. Nesse caso eu recomendo abrir um chamado com a VMware. No meu caso, a tabela vpx_text_array​​ estava com entradas corrompidas. Assim que as entradas foram deletadas, o dump ocorreu sem problemas e o​​ upgrade​​ concluiu.

 

Bom, essas foram as surpresas que eu já encontrei fazendo atualizações. Se vocês já encontram outras fiquem à vontade para deixar a sua experiencia nos comentários!

 

vRealize Operations 7.0 – Licenciamento

Olá pessoal, tudo bem?

Hoje eu queria esclarecer o licenciamento da versão 7.0 do vROps. O vRealize Operations Manager já está na versão 7.0 e, para quem estava acompanhando, sabe que a solução passou por uma mudança grande na versão 6.7.

Cadê as métricas??

Para quem estava acostumado e usava bastante as métricas disponíveis percebeu que a partir da versão 6.7 foi feita uma limpa nas métricas. O objetivo era deixar a ferramenta mais intuitiva e fácil de gerenciar e administrar. Depois do trauma de perder algumas métricas, eu acredito que a mudança foi para o melhor. A ferramenta ficou mais simples de entender e trouxe consigo a precificação de nuvem privada! Essa funcionalidade estava disponível somente no vRealize Business e agora, se você já fez o upgrade para o vROPs 6.7 você já pode usufruir também da funcionalidade! Existem outras funcionalidades também, posso comentá-las em um post futuro.

Se você está interessado em saber quais métricas deixaram de existir ou foram substituídas é só checar esse link AQUI.

Mas voltando ao foco! O upgrade da versão 6.6 para a versão 6.7 pode ser feita sem problemas porque não é uma mudança de versão. Ambos estão em 6.X. Agora para a versão 7.0 temos que tomar cuidado.

Posso fazer o upgrade para a versão 7.0?

Se você está nas versões 6.X e possui um contrato de subscrição e suporte (SnS) ativo com a VMware, você pode fazer o upgrade da ferramenta. Como isso vai acontecer depende de como o seu vROPs é licenciado.

Se o seu vROPs é licenciado pela licença vSOM, não é necessário fazer nenhuma mudança pois essa licença não é invalidada de acordo com o Release Notes do vROPs 7.0. Mas eu deixo aqui um ponto de atenção: o licenciamento vSOM foi descontinuado! (Leia AQUI sobre esse End Of Availability)

Se você possui a licença vRealize Suite 6.0 a mesma será invalidada. Então ao realizar o upgrade o seu novo vROPs irá aparecer em Evaluation Mode (o trial de 60 dias). Se você possui o SNS ativo com a VMware você irá conseguir realizar o upgrade da licença do vROPs para a versão 7.0 a partir do portal MyVMware! Após gerar a nova licença, basta aplica-la no vROps.

Segue KB que explica com mais detalhes as licenças com direito de upgrade: KB 2142365

Caso você não tenha o SNS ativo, será necessário adquirir uma nova licença antes da finalização dos 60 dias de teste para continuar usufruindo da ferramenta na versão 7.0.

Leia o Release Notes!

É extremamente importante ler o Release Notes antes de realizar qualquer upgrade. Além de trazer as novidades, problemas resolvidos e problemas conhecidos esse documento irá informar quais os caminhos de upgrade possíveis e se tem algum ponto importante que deverá ser levado em consideração no planejamento do upgrade. É uma leitura rápida que poderá te poupar bastante dor de cabeça! Então não esqueça de checar o Release Notes vROPS 7.0 !

Porque NSX?

Olá pessoal! Vamos conversar sobre NSX?

Antes de começar a estudar ou entender um produto eu sempre gosto de pincelar quais as “dores” que esse novo produto veio para resolver. Afinal tecnologias e produtos novos geralmente surgem para suprir uma necessidade (resolver um problema ou tornar algo mais eficiente). Então, a pergunta que não quer se calar: porque usar NSX?

Sobe uma VM aí pra mim!

Hoje em dia nós temos um número muito maior de máquinas do que antigamente. Antes o nosso limite era o que cabia no rack. Com a virtualização a tarefa de criar uma máquina se tornou muito mais ágil e fácil. Com literalmente alguns cliques você já tem uma máquina virtual. (Se usar template então, menos cliques ainda.)

Então se antigamente em um rack cabiam 24 servidores, cada um com o seu sistema operacional instalado, hoje em dia podemos instalar o hipervisor e ter mais de 100 máquinas virtuais por servidor (imagina um servidor bem servido de CPU e RAM hehe)!

E como que ficou a nossa rede? Geralmente encontramos em cima do rack um switch topo de rack (TOR). No nosso ambiente antigo com 24 servidores cada um com uma interface de rede teríamos 24 cabos ligando no nosso switch. Ou seja, o switch aprende 24 endereços MAC. E com as nossas máquinas virtuais? Agora ele tem que aprender mais de 100. Isso supondo que cada máquina virtual tem somente 1 interface de rede!

Outro ponto, a agilidade de subir uma máquina virtual não repassou para outras equipes. Para subir um portgroup novo no switch standard ou no switch distribuído em uma nova VLAN é necessário configurá-la em todos os switches além de criar as devidas rotas para a comunicação desse novo segmento de rede. Dependendo da topologia de rede, essa tarefa pode ser bem onerosa.

E não basta só passar a VLAN e configurar as rotas! Temos ainda que conversar com a equipe de segurança para aplicar a política de segurança para esse novo segmento.

Desse cenário podemos puxar dois pontos:

  1. Os equipamentos de rede estão tendo que processar um grande número de máquinas virtuais comparado com antigamente.
  2. O esforço para a entregar uma máquina virtual ainda está alto por causa de tarefas manuais. E ainda pode ser inseguro, pois por ser manual, não está livre dos possíveis erros!

Luz no fim do túnel

Com o cenário anterior em mente fica mais fácil de entender como uma solução como o NSX pode ajudar. O NSX irá trazer as funcionalidades de rede como switching, roteamento e firewall para dentro do hipervisor. Ou seja, essas funções serão aplicadas em nível de kernel. Dessa forma podemos ter as seguintes melhoras:

  • Segurança:   A segurança é garantida direto no hipervisor sendo possível configurar regras de firewall com micro segmentações. É aqui que é implementada a segurança leste-oeste, protegendo não só o perímetro do ambiente como também máquinas virtuais dentro do mesmo segmento de rede.
  • Automação: Ao trazer as funções de rede para o kernel é possível automatizar o seu provisionamento deixando as configurações rápidas, padronizadas e consistentes entre as aplicações.
  • Continuidade do negócio: Podemos  também garantir a mobilidade de máquina virtual entre sites ao expandir as funções de roteamento e firewall entre sites. Ou seja, pensando em sites DR ou ambientes cross-vCenter, independente de qual site a a máquina virtual se encontra, ela ainda possuirá suas políticas de segurança e suas configurações de rede.

Agora que sabemos porque usar o NSX você deve estar se perguntando: como o NSX consegue entregar segurança, automatização e continuidade das aplicações? Essas serão cenas do próximo capítulo, aguardem!

 

Bem vindos – Priscilla Rega

Olá comunidade! Meu nome é Priscilla Rega e eu sou graduada em Engenharia de Redes de Comunicações pela Universidade de Brasília. Atualmente eu trabalho com projetos focados em soluções VMware. Possuo as certificações VCP em datacenter, NSX e Cloud Automation e sou completamente apaixonada pelas soluções!

A minha curiosidade em saber exatamente como cada solução funciona me levou a consumir todos os blogs e fóruns de comunidade que pudesse encontrar. Eu queria aumentar meu conhecimento na área e meu entendimento nas tecnologias.  E nessa saga encontrei artigos de altíssima qualidade! Artigos que me ajudaram a resolver problemas sexta-feira de madrugada, artigos que me fizeram finalmente entender um conceito ao explicar de uma forma diferente, artigos que me fizeram ter interesse em uma nova tecnologia. Eu sou extremamente grata a essa comunidade e sinto que atualmente estou em uma posição de poder retribuir essa ajuda!

Com esse blog eu espero poder contribuir ao compartilhar os problemas que encontro em implementações (e salvar alguns finais de semana e madrugadas se possível), explicar conceitos básicos de formas diferentes para ajudar no aprendizado da tecnologia e basicamente repassar aqui tudo o que eu acho que poderia ajudar.

Sejam bem vindos e vamos lá!