Script de migração de VMware Distributed Porgroup para Nutanix Prism Element

Fala rapaziada !

Hoje nosso post de hoje será sobre um script que me aventurei a fazer com a intenção de evitar a fadiga.

O cenário para utilização deste script é diversificado, podendo ser ajustado para implementações/migrações de ambiente VMware para AHV e operação do dia a dia quando se trata de criação de Networks no Nutanix

Requerimentos para funcionamento do script:

  • VMware Powershell 7
  • Nutanix cmdlets para AOS 6 (Não testei em alguma versão do AOS 5.x )

Vamos ver a composição do script:

#Carrega os módulos de Nutanix cmdlets
if ([string]::IsNullOrEmpty($(Get-PSSnapin -Name NutanixCmdletsPSSnapin -Registered -ErrorAction SilentlyContinue))) {if (Test-Path "C:\Program Files (x86)\Nutanix Inc\NutanixCmdlets\powershell\import_modules\ImportModules.PS1") {

. "C:\Program Files (x86)\Nutanix Inc\NutanixCmdlets\powershell\import_modules\ImportModules.PS1"

} else {

Write-Error "Could not load NutanixCmdletsPSSnapin"

}

} else {

if ([string]::IsNullOrEmpty($(Get-PSSnapin -Name NutanixCmdletsPSSnapin -ErrorAction SilentlyContinue))) {

Add-PSSnapin NutanixCmdletsPSSnapin

}

}

#Carrega os módulos de VMware powercli 
Import-module VMware.PowerCLI


#Declara as variáveis do VMware
$vCenter = "vc-server"
$usernamevmw = "administrator@vsphere.local"
$passwordvmw = "vc-password"
$file = "C:\Users\silwm\Downloads\teste-vlan.csv"


#Conecta ao vcenter
Connect-VIServer -Server $vCenter -User $usernamevmw -Password $passwordvmw -force


#Exporta as informações de portgroup e vlanid
$report= foreach ( $vds in get-vdswitch | Select-Object -ExpandProperty Name ) {

foreach ( $vdsPG in $vds ){ 
 Get-VirtualSwitch -name $vds | Get-VirtualPortGroup | `Select Name,VirtualSwitch, @{N = 'VLANId'; E={$_. Extensiondata.Config.DefaultPortCOnfig.Vlan.VlanId}}
 
}
}
echo $report | Where-Object {$_.Name -like "*VLAN*"} | Export-Csv C:\Users\silwm\Downloads\teste-vlan.csv
(Get-Content $file) | Foreach-Object {$_ -replace '"', ''}|Out-File $file


#Declara as variáveis do Nutanix
$clusterntx = "PE-clusterIP"
$usernamentx = "PE-admin"
$passwordntx = "PE-password"

Connect-NutanixCluster -Server $clusterntx  -UserName $usernamentx -Password $passwordntx -AcceptInvalidSSLCerts -Verbose 

$cvs = Import-Csv C:\Users\silwm\Downloads\teste-vlan.csv


foreach ($vlan in $cvs) {

New-NTNXNetwork -Name $vlan.Name -VlanId $vlan.VLANId


}

Get-NTNXNetwork

Os dois blocos iniciais são para a importação dos módulos de cmdlets do VMware e Nutanix. A terceira etapa e mais importante, na minha opinião é a conexão ao vCenter e obtenção das informações de portgroup e vlanid do ambiente VMware, sendo exportado para formato csv e filtrando todo portgroup que contenha a palavra VLAN para filtrar somente os objetos de interesse.. O quarto e último bloco é conectar ao Prism Element e criar os portgroups no cluster Nutanix.

Na minha implementação há somente um VDS e o destino será um Open-vSwitch, mas há espaço para customização e seleção de múltiplos VDS para Open-vSwitch.

Espero que isso possa ajudar os amigos no dia a dia!!

Forte Abraço

Instalação do vRealize Suite Lifecycle Manager 8.4

Procedimento para instalação do vRealize Lifecycle Manager 8.4.

Patching with vRealize Suite Lifecycle Manager - Vedaa.net

A vida de operação de TI é rápida e não permite perder tempo, quando tratamos implementação a premissa é a mesma, pois a arquitetura a ser implementada deve ser fácil e rápida de implementar e principalmente prática e fácil de manter para otimizar o precioso tempo das equipes de Operação. Visando atender ambas as equipes foram criadas soluções de LifeCycle Manager, que permitem facilitar a implementação e atualização dos componentes (patchs, movas versões e firmwares) para diversas soluções de TI.

A VMware tem soluções de Lifecycle Manager em seu portifólio para diversas soluções. A mais conhecida era o VUM VMware Update Manager que permite aplicar atualizações de patchs e versões de ESXi, mas o VUM passou por um upgrade na versão 7 do vSphere e mudou de nome, sendo agora conhecido como vSphere LifeCycle Manager, que incorporou as funções do VMware Update Manager e adicionou mais função como Update Planner para a atualização do vCenter e seus componentes.

A Suite vRealize Suite possui o LCM que permite realizar a implementação e gerenciamento de atualizações das soluções, que compõem o vRealize Suite:

  • vRealize Automation
  • vRealize Operations Manager
  • vRealize LogInsight
  • vRealize Network Insight
  • vRealize Business for Cloud
  • vRealize Workspace One

Com isso iremos seguir o passo a passo da instalação do LCM 8.4 para demonstrar o processo de implementação da ferramenta e posteriormente em outro post iremos demonstrar a implementação do vRealize Operations através do LCM.

Criação de Role e usuário para o LCM

  • Clicar em Menu > Administation
  • Selecionar a opção Roles em Acess Control
  • Clicar selecionar a role Read-only
  • Preencher o campo Role name
  • Preencher o campo Description
  • Clicar em OK
  • Selecionar o perfil criado
  • Clicar no ícone de lápis para editar

  • Selecionar a opção Datastore
  • Marcar as permissões necessárias conforme imagem
  • Clicar em Finish
  • Clicar em User and Groups
  • Selecionar o local onde o usuário seria criado, podendo ser o domínio SSO do vCenter ou AD
  • Clicar em ADD
  • Preencher as informações do usuário
  • Clicar em Global Permissions
  • Clicar no ícone +
  • Localizar o usuário criado
  • Selecionar a Role criada
  • Marcar a opção Propagate to children
  • Clicar em OK

Instalação do LCM

  • Caso esteja usando Windows 10 só clicar duas vezes na ISO de instalação do LCM
  • Acessar a pasta X:\vrlcm-ui-installer\win32-lite
  • Executar Installerlite.exe
  • Clicar em Install
  • Clicar em Next
  • Marcar a opção “I Accept the terms of the license agreement”
  • Clicar em Next
  • Preencher o campo vCenter Server
  • Preencher o campo HTTPS Port
  • Preencher as informações de credenciais
  • Clicar em Next
  • Aceitar o thumbprint do certificado do vCenter, clicando em ACCEPT
  • Selecionar a pasta que a VM do LCM ficará armazenada no vCenter
  • Clicar em Next
  • Selecionar o cluster que será utilizado para hospedar a VM do LCM
  • Clicar em NEXT
  • Selecionar o Datastore
  • Selecionar a opção thin Disk mode dependendo do seu ambiente, como estou em um ambiente de PoC e armazenamento é limitado foi selecionado Thin Disk.
  • Clicar em Next
  • Preencher as informações de rede para a VM do LCM
  • Clicar em Next
  • Preencher as informações de Senha
  • Clicar em Next
  • Preencher o campo Virtual Machine
  • Preencher o campo iP Address
  • Preencher o campo hostname
  • Preencher o campo Datacenter name – Este campo será utilizado para determinar o ambiente onde as soluções da VMware serão instaladas
  • Preencher o campo vCenter Name
  • O campo Increase Disk Size in GB aumentará o espaço em disco padrão da VM do LCM
  • Clicar em NEXT
  • Clicar em Submit
  • Aguardar o processo de implementação
  • Clicar na URL
  • Clicar em OK
  • Preencher o campo username com admin@local
  • Preencher o campo pasword com a senha definida durante a instalação

Com isso realizamos a implementação do LifeCycle Manager e no próximo post iremos realizar a configuração do LCM.

Vagrant up and running !!

Image result for vagrant

Meus brothers, desculpe a ausência, mas vida de IT Guy e Pai é complicado, a criançada lá de casa ficou doente e acabei ficando doente também, mas vida que segue.

No posto de hoje vamos falar sobre o Vagrant da Hashicorp, uma ferramenta bem legal que eu comecei a usar para atender um projeto com o time de desenvolvimento da empresa e acabei adotando no meu dia a dia e nos meus estudos sobre Linux.

Você pode estar questionando sobre os posts de NSX-T eles retornarão em breve.

Mas aí você me pergunta: O que é o Vagrant ?

Vagrant é uma ferramenta para provisionamento de um ambiente de desenvolvimento usando principalmente máquinas virtuais.

Mas aí você pergunta novamente: Qual é a vantagem ?

O Vagrant diminui o tempo de setup de um ambiente de desenvolvimento e aumenta a semelhança de um ambiente de produção e desenvolvimento .

No meu caso eu uso o Vagrant para provisionar VMs linux no meu notebook ou no meu ambiente VMware para estudos com containers, microserviços e serviços linux sem precisar ficar perdendo tempo com instalação de sistemas operacionais e provisionamento de serviços. O Vagrant permite o provisionamento com shell script ou ferramentas de gerenciamento de configuração como Ansible, Puppet ou Chef.

O Vagrant permite o provisionamento de recursos através das seguintes plataformas:

  • Virtual box
  • VMware Workstation
  • KVM
  • AWS
  • Vsphere
  • Hyper-v
  • Docker

Aí você fala legal, mas quero ver funcionando!!!

Não vou abordar a implementação do Vagrant, devido o próprio fabricante fazer isso muito bem, então se quiser aprender sobre o Vagrant como as demais ferramentas da Hashicorp é só clicar no link abaixo e se divertir:

https://www.vagrantup.com/intro/getting-started/install.html

O cenário que irei demonstrar é o provisionamento de uma VM Linux Centos 7, com LAMP para suportar o WordPress. Neste teste estou usando meu notebook com Fedora Linux 30, Vagrant e Virtual Box, mas Windows e Mac são suportados e o mesmo arquivo (Vagrantfile) de provisionamento pode ser utilizando entre os sistemas operacionais.

Após a implementação do Vagrant começamos com a criação de um Vagrantfile, através do comando vagrant init

Este comando cria o arquivo Vagrantfile no diretório atual do usuário

o conteúdo do arquivo é este . No caso abaixo removi os comentário e só deixei as instruções inicais do arquivo sem customização.

Mas para o nosso teste irei utilizar um arquivo customizado

Vagrant.configure(“2”) do |config|
config.vm.provider “virtualbox” do |v|
v.linked_clone = true
#v.gui = true
end

config.vm.define “srv01” do |subconfig|
subconfig.vm.box = “centos/7”
subconfig.vm.synced_folder “.”, “/vagrant”, disabled: true
config.vm.synced_folder “/home/silvio/vagrant”, “/files”
subconfig.vm.hostname = “srv01”
subconfig.vm.network “private_network”, ip: “172.28.128.2”
subconfig.vm.provision “shell”, path: “base.sh”
subconfig.vm.provision “shell”, path: “lamp.sh”
end

end

O campo Vagrant.configure utilizo para configuração do virtual box, como utilizar linked clone, entre outras opções.

O campo config.vm.define é utilizado para a criação da vm e provisionamento dos serviços ofertados pela VM. O campo subconfig.vm.provision é utilizado para chamada de shell script para instalação de pacotes e serviços no Linux, lembrando que posso utilizar ferramentas de gerenciamento de configuração para provisionamento, mas iremos utilizar um shell script, bem básico para isso.

O campo subconfig.vm.box define o SO que será utilizado, mas o termo utilizado no Vagrant é box. Há um catálogo de boxes que pode ser utilizado pelos usuários e a ferramenta Packer da Hashicorp permite a criação de boxes customizadas, que podem ser enviadas para o catálogo.

Mas e aí qual é o resultado !!!

Vamos de vídeo que fica mais mais fácil demonstrar.

Provisionamento de um servidor com LAMP e WordPress

Fizemos a implementação de um servidor Centos com LAMP e WordPress provisioando com o Vagrant.

Dentro do Vagrant fiz a chamada dos scripts abaixo:

Base.sh

#!/bin/bash

#Install base softwares

yum install -y vim git2u unzip socat net-tools.x86_64 vim-common.x86_64 vim-enhanced.x86_64 make wget yum-utils epel-release

#Install repos

yum -y install http://rpms.remirepo.net/enterprise/remi-release-7.rpm
yum -y install epel-release yum-utils
yum-config-manager –disable remi-php53
yum-config-manager –disable remi-php54
yum-config-manager –disable remi-php55
yum-config-manager –enable remi-php73
yum update -y

#Setup timezone

timedatectl set-timezone America/Sao_Paulo

lamp.sh

!/bin/bash

cat > /etc/yum.repos.d/mariadb.repo << EOL

[mariadb]

name = MariaDB
baseurl = http://yum.mariadb.org/10.3/centos7-amd64
gpgkey=https://yum.mariadb.org/RPM-GPG-KEY-MariaDB
gpgcheck=1
EOL

#Install LAMP

yum install httpd mariadb mariadb-server php php-common php-mysql php-gd php-xml php-mbstring php-mcrypt -y

#Mariadb

systemctl start mariadb
systemctl enable mariadb
sudo mysql -e “SET PASSWORD FOR root@localhost = PASSWORD(‘VMware1!’);FLUSH PRIVILEGES;”
printf “VMware1!\n n\n n\n n\n y\n y\n y\n” | sudo mysql_secure_installation

#create database

MYSQL_PASS=’VMware1!’
export MYSQL_PASS
mysql -uroot -pVMware1! -e “CREATE DATABASE db_wordpress;”;
mysql -uroot -pVMware1! -e “GRANT ALL PRIVILEGES on db_wordpress.* to ‘wordpressuser’@’localhost’ identified by ‘password’;”;
mysql -uroot -pVMware1! -e “FLUSH PRIVILEGES”;
mysql -uroot -pVMware1! -e “exit”;

#HTTPD PART1

systemctl start httpd
systemctl enable httpd

#WORDPRESS

cd /tmp && wget http://wordpress.org/latest.tar.gz
tar -xvzf latest.tar.gz
sudo cp -avr wordpress/* /var/www/html/
mkdir -p /var/www/html/wp-content/uploads
sudo chown -R apache:apache /var/www/html/
sudo chmod -R 755 /var/www/html/
cd /var/www/html/
sudo cp wp-config-sample.php wp-config.php

#Firewall

firewall-cmd –permanent –zone=public –add-service=http
firewall-cmd –permanent –zone=public –add-service=https
firewall-cmd –reload
setenforce 0

No final do provisionamento faço somente o configuração do banco de dados, usuário e senha para conexão do WordPress com o Mariadb.

Estarei usando o Vagrant no meu dia a dia e havendo novidades eu post aqui os setups que tenho feito.

Forte abraço !!

Implementando o EDGE do NSX-T

Fala pessoal !!

Hoje iremos abordar a implementação do EDGE do NSX-T. o Edge tem como função prover serviços de roteamento (Tier0 e Tier1) e conexão do ambiente virtual com o ambiente externo.

Não há como não citar a diferença do provisionamento de um EDGE do NSX-T com o seu antecessor NSX-V. O NSX-V provisionava o EDGE de forma on-demand ao demandar os recursos de distributed routing, através da Control-VM ou ao solicitar a adicão de edges para função de integração com a rede física, com isso tratando o tráfego norte-sul ou para oferta de serviços de load balance em modo in-line ou one-armed. O NSX EDGE por sua vez faz

O modo como o EDGE foi arquitetado no NSX-T é diferente, comparado com o NSX-V, sendo um a primeira diferença a oferta de EDGE em modo baremetal adicionalemente ao formato VM, permitindo maior performance com a integração da instrução Intel DPDK (Data Plane Development Kit) tanto no formato VM como baremetal. O EDGE somente é suportado em hosts ESXI com chipset Intel, caso este requesito não for atendido o processo de inicialização do EDGE não ocorrerá corretamente. Outro ponto é a inclusão de serviços de roteamento através de roteadores tier0 e tier1 com suporte a serviços statefull e loadbalance. Trataremos esta diferenciação mais a frente no momento da configuração dos serviços de Tier0 e Tier1 dentro do EDGE01 que provisionaremos, mas fazendo spoiler veja o EDGE do NSX-T como um container.

Só para relembrar no ultimo post ficamos com a seguinte topologia:

Requerimentos NSX Edge VM:

O NSX Edge Small é recomendados para ambiente de PoCs ou laboratórios (vxlab :-P).

O NSX Edge Medium é adequado para ambientes de produção

O NSX Edge Large é adequado para serviço do load balance

NSX EDGE VM requerimentos de CPU:

Para o suporte ao DPDK o hardware deve possuir as seguintes configurações mínimas:

  • CPU deve suportar instrução AESNI
  • CPU deve ter suporte a 1G de HUGE Pages

Requerimentos NSX Edge baremetal:

NSX EDGE baremetal requerimentos de CPU:

Para o suporte ao DPDK o hardware deve possuir as seguintes configurações mínimas:

  • CPU deve suportar instrução AESNI
  • CPU deve ter suporte a 1G de HUGE Pages

Requerimentos de hardware do NSX EDGE baremetal:

Para verificar os hardwares homologados como Edge baremetal utilizar a URL abaixo:

https://certification.ubuntu.com/server/models/?release=18.04%20LTS&category=Server

Requerimentos de interface de rede do NSX EDGE baremetal:

Requerimentos de portas TCP e UDP

Instalação do NSX EDGE

Requerimentos:

  • Plaformas: ESXi host ou Baremetal. NSX EDGE não é suportado em ambiente KVM
  • Password que atenda o requerimento de complexibilidade
  • Caso o critério de complexibilidade não seja atendido, afetará a inicialização dos serviços do EDGE.

Selecionar o diretório onde o OVA do NSX Edge foi armazenado
Selecionar o cluster para hospedar o cluster de NSX EDGE.
Clicar em NEXT
Selecionar a configuração do EDGE necessário para o ambiente
Selecionar o datastore
Selecionar os portgroups.
Inicialmente iremos utilizar a network interface 0
Preencher os campos requisitados
Finalizar a implementação do appliance

Registrar o NSX EDGE ao NSX-T Manager

  • Acessar via SSH o NSX Manager
  • Executar o comando get certificate api thumbprint para obter o thumbprint do NSX Manager
  • Acessar via SSH o NSX EDGE
  • Executar o seguinte comando no NSX EDGE : join management-plane IP_MANAGER username admin thumbprint <TUMBPRINT DO NSX MANAGER>
  • Preencher o campo “Password for API” user com a senha de admin do Manager
  • Verificar a confirmação de registro

Nossa topologia após a implementação ficou da seguinte maneira:

Neste post nos implementamos o NSX EDGE na Management Plane do NSX-T permitindo utilizar o EDGE para provisionar roteador Tier0 e roteadores Tier1. No proximo post iremos tratar a configuração e provisionamento dos recursos de redes físicas para a configuração dos transport nodes na management plane.

Qualquer dúvida ou sugestões estou a disposição.

NSX-T Manager for vSphere

Pessoal, conforme falei anteriormente estarei abordando a implementação do NSX-T no meu homelab e estarei aproveitando o momento para estar gerando material para o meu blog e consequentemente compartilhar o conteúdo.

Neste momento estarei abordando as nuances da implementação dos componentes do NSX-T, mas futuramente estarei detalhando a função de cada um deles e tratando os casos de uso da solução também.

Havendo dúvidas, por favor, entrem em contato, pois um ambiente colaborativo é saudável e ajuda a aumentar o conhecimento de todos.

Antes de iniciarmos a implementação do NSX-T Manager é necessário sintetizar o processo de implementação do NSX-T Manager:

  1. Levantamento de requerimentos
  2. Liberação de portas e protocolos necessários para comunicação
  3. Instalação do NSX-T Manager
  4. Adição do Compute node ao management plane

1. Requerimentos:



O NSX-T Manager vem em 4 formatos de requerimento de recursos , mas com um ponto de atenção para o appliance extra small que atende ao papel de Cloud Service Manager para o NSX Cloud, não sendo possível utilizá-lo como NSX Manager para gerenciamento de compute node , edge node ou host node para ambiente on-premises.

No meu ambiente estará sendo utilizado o appliance small VM , devido menor requerimento de recursos de hardware.

Pontos de atenção para ambiente produção:

  • Latência de 10 ms entre os NSX Managers que participam do management cluster
  • Latência de 150 ms entre os nós de transporte e o cluster ou NSX Manager
  • latência de 10 ms no storage que receberá o cluster ou NSX Manager

2. Portas de comunicação

3. Instalação do NSX Manager

Pontos de atenção:

  • Endereço IP estático
  • registro A e PTR criados no DNS server (sem utilização de underscore > _ <)
  • Endereço do servidor NTP
  • Endereço do servidor DNS
  • Password atendendo os critério de complexibilidade do appliance (Caso isso não seja atendido, o processo de provisionamento do appliance utilizará as senhas padrões das contas: admin|Default e root|vmware).
  • Caso o critério de complexibilidade não seja obedecido o core service do appliance não será inicializado, sendo necessário atender este critério para prosseguir com a configuração do appliance.
  • Portgroup criado no ESXi criado para o ambiente de do NSX-T. Normalmente implementado em uma rede de gerência.

TOPOLOGIA

Topologia antes da instalação do NSX-T Manager
Implementar o .OVA no ambiente do vCenter já implementado
Definir o nome da VM e a localização dentro do ambiente de vCenter
Selecionar o cluster ou host que hospedará o VM do NSX-T Manager
Selecionar o sizing do NSX Manager de acordo com o ambiente que deverá ser suportado
Selecionar o datastore respeitando os requesitos de espaço e performance
Definir o Portgroup e endereçamento do NSX-T Manager
Definir os passwords para os usuários do appliance.


Finalizar a configuração e aguardar a instalação do appliance.
Acessar o appliance através do IP e utilizar o usuário admin para login
aceitar os termos do CEIP, caso necessário
Clicar em FABRIC NODES
Clicar em COMPUTE MANAGERS
Clicar em ADD
Preencher os campos requeridos
Clicar em ADD
Clicar em ADD
vCenter server integrado com o NSX-T Manager.
Esta configuração permitirá a instalação do NSX-T Edge, compute node e demais configurações.
Topologia com a instalação do NSX-T Manager

No próximo post realizaremos a instalação do NSX-T Edge e a inclusão dele no management plane do NSX-T.

Introdução

NSX-T Datacenter tem como foco fornecer segurança de rede, automação e simplicidade operacional para aplicações de diversos modelos de arquiteturas, mas com foco principalmente em microserviços e ambientes computacionais heterogêneos. O NSX-T Data Center oferece suporte a aplicativos nativos da nuvem, cargas de trabalho bare-metal, ambientes com diversos hypervisors, nuvens públicas e hybrid clouds.

O NSX-T Data Center é projetado para gerenciamento, operações e consumo por organizações de desenvolvimento. O NSX-T Data Center permite que as equipes de TI e desenvolvimento selecionem as tecnologias mais adequadas para seus aplicativos.

Os posts futuros estarão cobrindo a instalação dos componentes do NSX-T e a aplicação deles em uma arquitetura de rede com o objetivo de atender casos de uso para ambientes corporativos.

Documentação:

https://docs.vmware.com/en/VMware-NSX-T-Data-Center/index.html