Deploy de VCH – VIC 1.5.3

Fez o deploy do VIC e agora não sabe qual passo seguir? Não se preocupe, esse post foi criado para você!

Minha ideia é mostrar como fazer o deploy do VCH usando linha de comando. É possível fazer pelo plugin do VIC na interface HTML5 do vCenter mas vocês vão ver que, uma vez com o comando montado, criar e deletar VCHs é extremamente rápido! O wizard pela interface gráfica acabou sendo lento demais pro meu gosto hehe

O VCH ou virtual container host irá servir como um endpoint para comandos Docker. É por meio dele que será possível provisionar containers na infraestrutura VMware. A impressão que teremos é que estamos subindo containers dentro do VCH, mas por trás, cada container será uma máquina virtual no vCenter.

Mas vamos lá!

Primeiro passo é baixar os binários necessários para criar o nosso VCH. Eles estão disponíveis na página de gerencia do seu VIC! A URL é https://[IP_DO_VIC]:9443. Você pode clicar na parte destacada em vermelho para realizar o download!

Uma vez feito o download, você irá ver binários para Linux e para Windows. Nesse post eu vou usar uma VM com centOS7 e com o pacote docker instalado para realizar o deploy do VCH. Você pode jogar os arquivos dentro da VM via WinSCP, ou se você gosta de pular passos pode baixa-los diretamente da sua VM! Basta rodar os seguintes comandos:

wget [https]://[VIC_IP]:9443/files/vic_v1.5.3.tar.gz –-no-check-certificate

tar -zxvf vic_v1.5.2.tar.gz

Após extrair os arquivos, ele irá criar uma pasta chamada vic com todos os binários e arquivos necessários para subir um VCH!

Bom, agora chegou a hora de montar nosso comando. Abra o seu editor favorito (o meu tem sido o sublime!) e mãos à obra! Vou tentar separar aqui por partes! Como eu disse, nesse post irei usar o binário vic-machine-linux!

A primeira parte você vai dizer em qual ambiente será feito o deploy do seu VCH. Então vamos informar qual o vCenter, qual o Datacenter e o usuário que fará o deploy.

./vic-machine-linux create

–target vc01.nuvem.local/Datacenter

–compute-resource Cluster_MGMT

–user ‘[email protected]

–password ‘VMware1!’

Depois vamos informar quais certificados o VCH irá utilizar. Nesse post irei pedir para que seja criado um certificado auto-assinado, tanto para o VCH como para nossos clientes que irão se conectar ao VCH depois! Atenção: A pasta que guardará os certificados deve estar vazia ok? Senão ele reclama.

–tls-cname vch1.nuvem.local

–tls-cert-path /tmp/VIC_1.5.3/vic/Certs/

–organization NUVEM

–certificate-key-size 2048

Agora irei informar quais datastores o VCH poderá utilizar para armazenar imagens e volumes.

–image-store DS_NUVEM/VCH1_IMAGES

–base-image-size 8GB

–volume-store DS_NUVEM/VCH1_VOLUMES:ds_nuvem

Não podemos esquecer da rede! Para fazer o deploy de um VCH é obrigatório ter um port group para ser a rede BRIDGE do nosso VCH. É nessa rede que os nossos containers serão conectados quando forem criados! Outra rede que é obrigatória é a rede pública! Nessa rede iremos configurar um IP para que o VCH possa se comunicar com registros externos, ou seja, é interessante ele ter acesso à internet! No nosso caso, estará passando por essa interface também os tráfegos de clientes e de gerência. Não se preocupe, é possível separá-los casso seja necessário na arquitetura.

–bridge-network vch-bridge

–bridge-network-range 172.16.0.0/12

–bridge-network-width 16

–public-network MGMT

–public-network-ip 10.0.0.12/24

–public-network-gateway 10.0.0.254

–dns-server 10.0.0.2

O registro que iremos utilizar é o que já vem junto com o vSphere Integrated Container. Como no nosso caso ele está com um certificado autoassinado, eu preciso avisar ao VCH que ele pode aceitar esse Registry, mesmo ele sendo inseguro. A linha de baixo diz exatamente isso!

–insecure-registry vic01.nuvem.local

E por fim, o nome que será utilizado para criar a maquina virtual do VCH e o thumbprint do certificado do vCenter Server!

–name vch1

–thumbprint DE:6E:54:14:6B:D0:48:42:95:96:B2:6A:6C:6F:B6:7B:79:AF:61:04

Se você não sabe aonde pegar o thumbprint do certificado do vCenter, basta seguir as imagens abaixo.

Ufa! Eu sei que parece mais demorado do que seria pela interface gráfica, mas só precisamos montar esse comando uma vez. Depois podemos reaproveita-lo para subir outros VCHs, ou o mesmo várias e várias vezes 😊

Achou muito longo e não quer montar dessa forma? Quer só copiar e substituir pelas informações do seu ambiente? Acesse o comando pronto no arquivo vch_linux_cute no meu GitHub e use-o à vontade: https://github.com/priscillagr/VIC.git . Eles tem algumas opções a mais, mas é só retirá-las para ficar igual o desse post ok?

Ok. Agora que você tem o comando montado, você deve rodar ele dentro da pasta vic, aquela que tem o nosso binário vic-machine-linux! Vai ficar assim:

Aperte Enter e aguarde o deploy finalizar! Caso algo esteja errado, esse comando é bem bom de avisar o que pode ser. Tente ajeitar o que está de errado e tente novamente! A tela de instalação deve seguir assim:

Após finalizar, você terá essa tela da felicidade aqui:

Ele já te passa qual comando você deve rodar para puxar as informações do seu novo VCH! O meu comando no caso seria:

Ao rodar ele você vai ter essa saída aqui com todas as informações do seu VCH:

Mas peraí? Que trambolho de comando é esse? Não dá para ficar passando tudo isso de parâmetro toda vez que formos rodar algum comando no nosso VCH certo? Mas relaxa que o VIC facilitou para a gente! Se você lembra vem, você apontou uma pasta na qual os certificados foram criados. No meu caso é a pasta Certs. Dentro dela tem diversos certificados e um arquivo com o nome do nosso vch, chamado vch1.env. Esse arquivo possui as variáveis de ambiente que podemos exportar para o nosso terminal!

Ao exporta-las, podemos rodar um comando muito mais simples: Docker info! Ele já vai sabe para qual Docker host enviar.

Com isso nós temos o nosso VCH no ar, prontinho para ser utilizado. No próximo post irei mostrar como adicioná-lo a interface gráfica do VIC e como subir o seu primeiro container no ambiente VMware. Até lá!

Instalação de vSphere Integrated Contaner 1.5.3

Olá pessoal, tudo bem?

Resolvi subir o VIC 1.5.3 para ver quais novidades tem nessa versão. Resolvi postar aqui o passo a passo para fazer o deploy de um VIC e ajudar quem está começando nesse mundo de containers no VMware! Vamos lá?

  1. Primeiro passo é iniciar o deploy! O VIC 1.5.3 é um appliance .ova, então basta realizar o download e selecionar o arquivo.
  • Seleciona a pasta na qual o appliance será armazenado.
  • Selecione o host.
  • Confirme a versão e validação do seu OVA!
  • Leia e aceite os termos!
  • Escolhe o datastore. No meu ambiente como é lab, sempre seleciono thin provision para economizar espaço hehe
  • Selecione a rede! A rede MGMT é a mesma que se encontra o meu vCenter, então não terá roteamento para o VIC se comunicar com o vCenter.
  • Coloque as informações de rede do appliance, confira tudo e clique em Finish.
  • Assim que terminar o deploy, ligue o appliance e aguarde a tela de baixo aparecer. Iremos acessar a URL com o protocolo HTTP e o endereço IP registrado!
  1. No meu caso a URL era http ://10.0.0.8. Ele irá abrir uma tela para nós concluirmos a instalação, ou seja, iremos integrar com o vCenter. Nessa integração será instalado um plugin do vSphere Integrated Container. Ele será visível somente na interface HTML5!
  1. Após incluir as informações do vCenter e selecionar para instalar o plugin, aceite o certificado do vCenter Server.
  1. Se tudo estiver ok, irá aparecer uma mensagem em verde no topo da tela, informando que a instalação foi finalizada com sucesso!
  1. Podemos conferir na interface HTML5 o novo plugin.
  1. Caso apareça o alarme da Figura abaixo, não se assuste. Ele está reclamando do certificado autoassinado do VIC! Clique no link destacado em vermelho na Figura abaixo.
  1. Esse link irá mostrar uma tela com um aviso de certificado. Aceite esse aviso para que a tela mostrada abaixo apareça!
  1. Pronto! Não tem mais alarme nessa tela!

Nos próximos posts irei mostrar como fazer o deploy de um VCH via linha de comando! Até lá!

Reservar endereço IP no phpIPAM via Postman

Olá pessoal, tudo bem?

Estou seguindo um objetivo de aprender melhor como interagir com ferramentas e aplicações por meio de API. Afinal de contas, eu já ouvi diversas vezes que se uma ferramenta possui uma API você pode automatizá-la e facilitar a vida certo? Mas você só pode fazer isso se souber utilizar a API. Então nos meus primeiros passos tentei aprender a usar a API da ferramenta phpIPAM e conseguir, por meio de um cliente RestAPI, fazer a reserva automática de um endereço IP.

A idéia é fazer essa chamada rest ser feita depois pelo vRealize Orchestrator e assim ter um workflow para reservar um endereço IP para mim! Abaixo segue os passos que eu segui, espero que eles ajudem alguém que esteja fazendo algo similar.

Versões:

A versão do phpIPAM instalado é 1.5. A versão é importante porque eu estava tentando chamar uma função da API na versão 1.2 que não existia. Então para poupar dor de cabeça para vocês: sempre chequem a versão e quais funções da API estão presentes nela!!

O cliente Rest que eu vou utilizar é o Postman. Eu o adoro porque ele guarda todos os seus testes. Então se você logar no postman em outro computador ele irá trazer todas as suas requisições e os históricos delas!

Vamos lá!

O primeiro passo é acessar o meu IPAM. Clique em phpIPAM settings e desça até a parte de Feature Settings. Nela, habilite a opção de API e não se esqueça de salvar!

Depois disso, clique em API e crie um APP Id na interface gráfica do phpIPAM conforme Figura abaixo. Esse APP ID será utilizado em todas as requisições que iremos montar no PostMan. Como segurança eu estou usando a opção de User Token e dei permissão total.

Depois disso, abra o seu Postman para montarmos a nossa requisição. Temos duas requisições para montar. A primeira será para realizar o login e conseguir um token e a segunda é a nossa reserva de endereço IP.

De acordo com a documentação da API do phpIpam, para fazer login temos que fazer um POST na seguinte URL: http://[ipam_hostname]/api/APP_ID/user/

No meu laboratório a URL ficará http://ansible.nuvem.local/api/pri/user/ (ignorem o nome ansible, no meu lab eu costumo aproveitar a mesma VM pra tudo haha). Na Figura abaixo destaco o meu Postman mostrando que eu escolhi o método POST, a URL que eu irei enviar o POST e outro detalhe importante é a aba Authorization aonde eu escolho Basic Auth e vou inserir o meu usuário de login do IPAM. Ao clicar em SEND eu irei receber o Status 200 OK e um JSON de resposta com o meu token!

Agora para qualquer outra requisição que eu irei fazer, é necessário colocar o token no header da requisição! Vamos montar agora a nossa URL do POST para reservar o primeiro IP livre em uma subnet criada no phpIPAM. A URL padrão é a seguinte: http://[ipam_hostname]/api/pri/addresses/first_free/[subnet_ID]

Para descobrir a subnetID eu simplesmente vou pela interface gráfica, clico na minha subnet de destino e vejo pela URL qual o ID dela. O ID da minha rede 10.0.0./24 é 10.

Com essa informação e o meu token, vamos montar a requisição POST! A URL vai ficar: http://ansible.nuvem.local/api/pri/addresses/first_free/10

Além da URL, temos que inserir duas informações em headers: o token e o Content-Type. O Content-Type é necessário porque nesse POST eu irei enviar um JSON contendo as informações de hostname, descrição e dono que deverá aparecer na reserva no IPAM. Segue abaixo como fica a parte de Headers.

Depois de ajeitarmos os headers, vamos clicar em Body para colocar o nosso JSON com nossas informações! Eu escolhi o formato raw JSON.

Finalizada a montagem da nossa requisição POST, clicamos em SEND! O resultado esperado é 201 Content Created e um JSON com o nosso endereço IP reservado!

Vamos verificar no phpIPAM como ficou?

É isso! Espero que esse mini tutorial ajude quem esteja se aventurando em RestAPI! O próximo passo é fazer essa chamada usando o vRealize Orchestrator ao invés do Postman. Nos vemos lá!

Estamos a 2 dias para o VMworld 2019!

Pessoal, é com muita alegria, que pela quarta vez consecutiva, terei o privilégio de estar presente no VMworld! Sempre foi uma meta profissional participar deste evento e gostaria de contar um pouco da minha trajetória nos últimos anos. Até 2013 minha carreira sempre foi voltada para armazenamento e transporte de dados. Quando comecei a migrar esse foco para as tecnologias e produtos da VMware que uma enorme janela de oportunidades se abriu na minha vida profissional.

Confesso que foi até um pouco tardia essa guinada, mas hoje, não tenho qualquer dúvida que foi a melhor decisão tomada. Entrei de cabeça nessa jornada e foram dias e noites durante meses estudando e realizando os mais diversos laboratórios e testes. Nunca tive problema em fazer perguntas que, para pessoas experientes podem parecer simples, mas são fundamentais para o entendimento de qualquer tecnologia e mas por vezes, as pessoas deixam de fazer por algum tipo de vergonha.

Essa insistência e certa teimosia fez com que eu me desenvolvesse rapidamente nas tecnologias de virtualização e, em 2016 pela primeira vez, fui premiado pela empresa em que trabalho atualmente (IT-ONE) para representar o time de pós-vendas no evento.

Lembro que nesse primeiro ano meu foco foi em sessões, sessões e mais sessões técnicas. Enchi minha agenda até não caber mais. Estava muito ansioso em aproveitar ao máximo e trazer conhecimento para compartilhar e não decepcionar os que me confiaram essa missão. Até resgatei aqui no meu outlook minha agenda para o evento rsss:

Agenda meu primeiro VMworld em 2016

Foi bom? Com certeza, mas foi nos próximos anos que conto como conseguir aproveitar muito mais!

Para registro, algumas fotos do VMworld 2016, o primeiro na minha lista!

Badge VMworld 2016
Último dia em Las Vegas VMworld 2016
Cariello, eu e Edgar no VMworld 2016

Fotos acima: VMworld 2016

Em 2017 o foco foi um pouco diferente. Foi quando conheci o Valdecir Carvalho (http://homelaber.com.br/) que foi um grande incentivador e responsável pelo crescimento do VMUG no brasil e incontáveis iniciativas da comunidade local! Foi a partir dai que comecei a me dar conta que estar no VMworld era muito mais do que sessões técnicas. Foi desse encontro que me candidatei a ser um VMUG Leader da comunidade de Minas Gerais e que comecei a focar em relacionamento durante o evento.

Chegada VMworld 2017
Lounge VMworld 2017
VMUG Leaders Lunch VMworld 2017

Fotos acima: VMworld 2017

No ano de 2018, já com nosso VMUG ativo eu ganhei um ingresso do VMUG destinado líderes (VMUG Leader Pass) e isso facilitou e muito minha participação do evento visto que o ingresso é bem caro para nós que recebemos em Real… Nesse ano eu dediquei parte do meu tempo para trabalhar no VMUG Booth e tive oportunidade de interagir com diversos outros líderes e o foco foi relacionamento. Valdecir novamente me apresentou diversas pessoas da comunidade e a rede de relacionamento foi aumentando cada vez mais! Esse também foi minha primeira participação como vExpert e dediquei muito a relacionar com a comunidade! Incrível também pois no encontro exclusivo dos vExperts, Pat Gelsinger dedicou parte de sua concorridíssima agenda para falar conosco e render uma foto exclusiva!

Primeiro dia VMworld 2018
Comissão de clientes e colegas IT-ONE VMworld 2018
vCommunity VMworld 2018
Encontro Pet Gelsinger no evento exclusivo para vExperts no VMworld 2018

Fotos Acima: VMworld 2019

O VMworld é sem dúvida o maior evento de virtualização e computação em nuvem do planeta! A novidade pessoal para a edição de 2019 é que tenho um desafio, pois terei a missão de cobrir o evento com um ingresso especial para blogueiros (VMworld Blogger Pass) o objetivo é trazer conteúdo diário sobre as novidades através do meu Blog (em parceria com Thiago Caires e Priscilla Rega | http://www.itby3.com.br/) para a comunidade brasileira! A lista completa dos blogueiros oficiais deste ano pode ser conferida nesse site https://lnkd.in/dd2FAvz. Temos excelentes fontes de informações nessa lista contando com brasileiros feras como Ricardo Conzatti, Fernando Teixeira, Arles Sant Ana e Diego Oliveira! Não percam!!!

Para quem não puder comparecer, segue a dica para assistir ao vivo às “General Sessions” nas quais serão apresentadas em primeira mão a maioria das novidades e visão da VMware para o mercado. http://bit.ly/2KPtNc0.

Em breve volto com as atualizações e por enquanto deixo minha coleção de Badges que esse ano vai aumentar!!!

Coleção Badges VMworld

Abraços e até em breve!

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á!