NSX on Cisco Redes

VMware – Alcancei certificação VCP6-NV

Fri, 05 Oct 2018 00:00:00 +0000

Olá Pessoal,

Como podem verificar pelo título do post finalizei minha certificação ( 03/10/2018 ) baseado em uma carreira que estava olhando logo depois que havia passado na minha prova de CCIE. Baseando-se nos objetivos que eu tinha resolvi seguir esse caminho, pois são ítens que eu tenho interesse e havia visto que estava crescendo bastante no mercado.

Devido eu já ter feito minha prova de VSphere 6.0 ( Foundation ) com um detalhe que acabei não conseguindo seguir meu planejamento devido a diversos fatores ( pessoal e profissional ), mas eu ainda tinha essa pendência para que de fato eu pudesse concluir a certificação relacionado a ” Network Virtualization “. Para você que não conhece esse tracking recomendo olhar no site da VMware a trilha, porém o caminho apresentado seria como abaixo.

Com isso, meu intuito aqui neste post seria colocar os ítens que acabei utilizando para estudar para essa prova, e os recursos encontrados que acabaram me ajudando para enfim chegar nessa certificação. Como vocês sabem eu adquiri meu #vExpert que esta relacionado ao programa da VMWare voltado para nossa comunidade, ou seja, devido a isso todos os participantes tem acesso free aos treinamentos da Pluralsight. Devido a isso executei esses três treinamentos:

Após esses treinamento acabei partindo para os laboratórios que são disponibilizados pela propria VMware via HOL ( VMware Online Labs ), e vale ressaltar que são todos grátis, já que esses eu não iria conseguir simular em meu HomeLab. 😀 Segue abaixo os laboratórios executados para praticar o conteúdo:

HOL-1903-01-NET – VMware NSX Data Center for vSphere – Getting Started
HOL-1903-02-NET – VMware NSX Data Center for Security – Distributed Firewall and Micro-Segmentation
HOL-1903-03-NET – VMware NSX Data Center for vSphere – Operations and Troubleshooting for Network Engineers
HOL-1892-01-CHG – VMware NSX – Challenge Lab
HOL-1926-01-NET – VMware NSX-T Data Center – Getting Started

Em relação aos livros posso adicionar dois que ajudaram a consolidar mais os conceitos:

Esse livro você pode verificar na Amazon.

Esse livro é free e pode ser adquirido através desse link.

Aproveitando minha estadia na VMworld – Las Vegas aproveitei para focar em algumas palestras de NSX, devido a isso gostaria de compartilhar quatro sessões que achei interessante e você também pode assistir online pesquisando nesse link:

– Customer Panel on VMware NSX Data Center for Security (SAI2014PU)
– The Old Switcheroo: Migrate from VSS to VDS with Zero Downtime (VIN1170BU)
– NSX Data Center Load Balancing and VPN Services (NET2761BU)
– NSX-T Data Center Architecture and Benefits (NET1537BU)

Para concluir sobre os conteúdos tenho diversos sites que fui pesquisando os tópicos, mas vou compartilhar alguns que ajudaram de alguma forma a entender os tópicos:

QUIZ sobre NSX – ( http://www.elasticsky.co.uk/practice-questions/ )
Virtually Limitless – Transport Zones ( https://www.virtually-limitless.com/vcix-nv-study-guide/create-transport-zones-in-nsx/ )
buildVirtual – ESR ( http://buildvirtual.net/vcp-nv-deploying-an-edge-services-gateway/ )
Route to Cloud – DLR ( http://www.routetocloud.com/2014/06/nsx-distributed-logical-router/ )

Teria mais alguns para compartilhar, porém foi alguns que havia colocado nos favoritos e nesses próprios BLOGs existem mais conteúdos que podem ser estudados. Para finalizarmos gostaria de informar que essa certificação ( prova ) é executada em centro certificador ( Person VUE ) e outro fator importante para que você consiga o certificado de VCP existem alguns caminhos, que o primeiro seria obrigatoriedade de fazer o treinamento da VMware o que no meu caso não aconteceu, pois existe uma opção que as pessoas que possuem certificações Cisco podem fazer uma submissão a VMware que acaba sendo anulado obrigatoriedade do treinameto.

Espero que essas informações possa ajudar em suas decisões e que desperte talvez um interesse para seguir essa trilha. 😉

Abs,
Rodrigo

VMworld 2018 – Day 2 – Terça Feira

Wed, 29 Aug 2018 00:00:00 +0000

Olá Pessoal,

Continuando nossos posts diretamente da VMworld, hoje venho trazer um resumo de tudo que aconteceu durante meu dia no evento.

Dessa vez o keynote foi um pouco diferente, o segundo dia sempre tem algumas entrevistas com alguns clientes da VMware apresentada pelo Sanjay Poonen. O assunto dessa vez foi a Transformação Digital nas empresas, bem como o processo de evolução dentro do ambiente VMware, sendo mencionado como um ” Software Defined Everything “.

Server Virtualization – Ano 2000
Software Defined Storage – Ano 2009
Software Defined Networking – Ano 2012
Software Defined Digital Workspace – Ano 2014
Multi-Cloud, Hybrid Cloud and Virtual Cloud Networking – Ano 2016-2018

Alguns números foram mostrados falando sobre o impacto do NSX, contraste entre os diferentes ambientes ( On-premises, Hybrid Cloud, etc ) e a visão que a VMware tem para o futuro. Vocês podem observar esses ítens através dos slides que capturei na apresentação. Não estão perfeitos, mas acredito que vocês podem ter idéias sobre a projeção.

Enfim, o mais esperado dessa keynote era a palestra da Malala Yousafzai, vencedora do Nobel da Paz de 2014. Para quem não a conhece ela lutou muito pelo direito das pessoas, principalmente das mulheres, de ter acesso a educação no Paquistão durante a ocupação do Taliban que baniu as garotas das escolas. O mais interessante é que nessa época ela tinha apenas 14 anos, então é incrível uma criança dessa idade se preocupar tanto com a educação e o futuro do seu país. Durante a palestra a VMware anunciou que irá ajudar a fundação de Malala no seu trabalho pela luta da educação e das mulheres no mundo. Segue algumas fotos para vocês conhecerem a Malala.

Após o keynote eu vi algumas pessoas comentando qual a ligação entre a Malala e a VMware e por que ela? Acho que é difícil para alguns perceber a importância do trabalho dela se você cresceu e vive em um país desenvolvido. Mas no Oriente Médio a luta pelos diretos das mulheres e muito forte e por isso o trabalho da Malala é tão importante. Em uma área como a nossa, predominantemente masculina, acho que a mensagem que ela passa é bem clara. As mulheres precisam de mais espaço nesse mercado. Na área de infraestrutura a quantidade de mulheres é muito baixo e isso precisa mudar.

Após essa sessão segui meu cronograma indo para as apresentações relacionadas ao NSX para Service Provider. Em minha primeira sessão fiquei um pouco decepcionado, pois de fato não consegui visualizar aquilo que eu esperava trazendo design efetivos para Service Provider, mas muitas menções falando sobre as duas versão que temos ( NSX-V e NSX-T ) e seus comparativos o qual a principal diferença está relacionada ao suporte a implementção para VSphere e outra utilizando hypervisor distinto ( KVM, Openstack, etc ). Os pontos interessantes que eles trouxeram são algumas atualizações que estão sendo lançadas ( vCloud Director 9.5, NSX-T, NSX-V 6.4 ), e os esforços nesse momento que estão voltados para o desenvolvimento nas demandas de VPN ( L2 e L3 ). Seguem alguns slides:

Em minha segunda sessão técnica fui assistir “ Customer Panel on NSX SD-WAN by Velocloud “, na qual eles trouxeram 3 clientes com diferentes situações colocando assim as necessidades e dificuldades para fazer suas migrações de um ambiente legado ( MPLS ) para ambientes híbridos com a utilização de somente links de internet, breakout local para acessos as aplições em Cloud. Futuramente vou detalhar um pouco sobre esse bate papo, porém de fato eles mencionaram números e facilidades após essas migrações. As empresas participantes foram ” NorthGate Gonzalez, Equity Trust, Fidelity National Financial “.

Para finalizar o dia tivemos nossa festa do vExpert e para concluir tiramos uma foto com nada mais que o CEO da VMware Pat Gelsinger.

Continue acompanhando nosso BLOG que mais novidades serão publicadas!!! 🙂

Abs,
Rodrigo

VMware – NSX – Serviço de borda e DLR – Parte 4

Wed, 18 Jul 2018 00:00:00 +0000

Olá Pessoal,

Vamos continuar falando sobre nosso NSX, para isso hoje venho para detalhar um pouco sobre essas facilidades que temos dentro da solução a qual chamamos de Serviços de Borda “ Edge Services ” e Router Logico Distribuido ( DLR – ” Distributed Logical Router ” ).

Acredito que pelos termos vocês já podem imaginar que estas terminologias estão muito co-relacionadas com a funcionalidades de ” networking “, ou seja, qual seria as principais diferenças entre eles para que possamos fazer a implementação correta.

Ambos ESG e o DLR podem rodar protocolos dinâmicos ( OSPF, BGP ) ou não ( rotas estáticas ), porém o ESG é um router em uma VM, o qual pode oferecer maiores serviços em L4-L7 ( FW, LB, NAT, VPN ) e tanto o control plane como o data plane estão nesta VM. Nesta analogia você pode corresponder que o ESG muitas das vezes tem maiores características para as implementações relacionadas ao trafego ( North-South ), e não precisamos ficar preocupados com limitação de trafego, pois a capacidade já esta bem equalizada aos appliances e se pensarmos podemos colocar para que eles rodem em paralelo.

Agora quando mencionamos sobre o DLR seu data plane é distribuido nos módulos de ” kernel ” de cada vSphere host, enquanto o plano de controle é existente em uma VM, mas também dependemos do cluster ” NSX Controller ” para enviar as atualizações de roteamento para os módulo de ” kernel “. O DLR é único porque ele acaba sendo habilitado em cada ” hypervisor – ESXi “, para executar seu roteamento entre os segmentos da VMs ( web, app, database ), onde podemos fazer associação como sendo um router lógico onde cada ” hypervisor ” seria a ” line card “. Tendo esta analogia obviamente essas implementações estão mais relacionadas ao nosso trafégo ( East-West ), o que se pensarmos anteriormente tinhamos muito trafego sendo direcionado para estruturas de camadas superiores ( camade de distribuição e Core ) tendo nossa camada de acesso sendo feita através do switch ToR ” Top of Rack “.

Como demonstrado na figura um ponto importante que devemos considerar na visão de um DLR é que a comutação de dados ” data path ” não esta atrelada aos pacotes e somente faz sentido para as questões do plano de gerenciamento.

Para detalharmos sobre o DLR, podemos declarar 3 tipos de interfaces que podemos utilizar dentro desse ambiente:

Uplink: Utilizado pela VM de controle do DLR para se conectar ao roteador de borda ” upstream “, onde podemos caracterizar como sendo interface de trânsito dos dois mundos ( físico com lógico ). Nessa interface podemos habilitar o protocolo de roteamento, porém nunca na mesma interface podemos trabalhar com mais de um protocolo.
LIFs: Existe para o host ESXi ao nível de ” kernel “, ou seja, são as portas de camada 3 para atuarem como gateway padrão para seus segmentos de redes hospedados para as VMs.
Management: Gerenciamento do DLR para que você possa fazer acesso remoto na VM através de SSH ou até por questões de alta disponibilidade. Sempre devemos nos atentar que essa interface faz parte da tabela de roteamento, portanto apenas os dispositivos da mesma sub-rede podem alcançar essa interface.

Outro detalhe que podemos mencionar sobre o DLR estão relacionado aos MACs correspondentes as interfaces mencionadas anteriormente. Segue as menções:

vMAC: Relacionado a interface onde as máquinas virtuais se comunicam. Cada LIF terá um MAC virtual, porem esse MAC é o mesmo por todos os hosts que estão naquela instância e esse endereço nunca é visivel pela mundo físico.
pMAC: Relacionado a interface para o ambiente físico. Neste caso quando o DLR precisa rotear o tráfego para fora do ESXi esse endereço MAC que será utilizado, bem como esse não está relacionado a interface física ( NIC ) onde o proprio NSX criar esse MAC.

Observe que devido a movimentação da VM para default gateway ela não vai saber que estamos em um hosts distinto, pois o L3 ( IP ) e o L2 ( vMAC ) permanecem o mesmo, sendo que independente de onde esteja teremos esse roteamento, onde obviamente podemos nos deparar que isso será feito via VXLAN ( iremos abordar em nosso próximo post ).

Para nosso ESG como mecionado temos maiores caracteristicas relacionados a serviços adicionais que serão também detalhados posteriormente, pois nele será atrelado funcionalidades específicas que podemos oferecer ao nosso ambiente de redes. Segue como resumo o ” size ” pensando-se em características de serviços.

Espero que você tenham entendido mais um pouco sobre as funcionalidades e como mencionado em nosso próximo post iremos falar sobre VXLAN. 😉

Abs,
Rodrigo

VMware – NSX Manager e Controller – parte 3

Mon, 25 Jun 2018 00:00:00 +0000

Olá Pessoal,

Conforme mencionado em nosso último post, hoje venho aqui para detalhar de mais alguns ítens que estão relacionados ao entendimento do NSX. Acredito que antes de explicar os componentes é necessário colocar esse desenho abaixo para entendimento das demandas daquilo que é necessário para ter a solução completa, bem como os passos para seguir para sua instalação.

Como vocês podem observar, temos alguns ítens essencias para que possamos ter os componentes que irão fazer as relações na infra-estrutura do NSX. Inicialmente, se você está pensando em fazer essa implementação, existem dois pré-requisitos essenciais para continuar o seu projeto:

Sua implementação através do vSphere é obrigatório que esteja utilizando VDS ( vSphere Distributed Switch )
Para utilização do VDS é necessário ter a licença vSphere Enterprise Plus, desde que você tenha o 5.5 U2 ou anterior. Se tiver a versão 5.5 U3, 6.0.x, 6.5, 6.7 pode ter qualquer licença que inclua o Essential ou Essential Plus.

Após essas validações devemos seguir observando a implementação desses elementos que será o NSX Manager, e como puderam observar ele é o unico que você irá ter uma imagem ( .ova ) para instalar, e consequentemente ele tem o papel de fazer a interface de gerenciamento entre o usuario que está trabalhando com a infra.

Um dos pontos importante para mencionar que o NSX Manager não impacta em nenhuma característica seus dados, ou no caminho de seus dados, pois ele esta trabalhando com instruções que são recebidas pelo vCenter, Restful API, CMP. Obviamente, você pode associar que se você tiver qualquer ” outage ” nesse elemento / componente nada em sua infra será impactada no sentido de funcionalidades de comutação de trafego, regras de firewall, maquinas virtuais impactadas, ou seja, você apenas não irá conseguir naquele momento fazer qualquer change no seu ambiente.

Após essa menção devemos observar que precisamos fazer o registro do NSX Manager ao vCenter, ou seja, será feito um registro dentro do ambiente para que você possa fazer o gerenciamento da solução tudo através de uma única ” GUI ” do vSphere, mas devido a esse registro devemos sempre lembrar que o NSX Manager apenas se registra em um único vSphere, tendo sua relação sempre sendo 1:1. Para concluir sobre o NSX Manager posso deixar como uma referência que para fazer a implementação iremos precisar de 4vCPUs, 12Gb de RAM, 60Gb de Storage.

Com isso podemos seguir para a implementação de nosso NSX Controllers, exatemente no plural e como na figura, pois o mínimo requisitado pela solução é que tenhamos 3 Controllers e sempre o ideal que tenhamos essas controllers instaladas em hosts distintos para que seja feita a correta resiliência nessa camada importantíssima que está atrelada ao nosso “ Plano de Controle “. Outro ponto importante é que podemos ter mais controllers instaladas no ambiente, mas devemos sempre seguir a regra de que seja instalado números ímpares e nunca sejam feito o deploy deixando controllers em quantidade pares.

Acredito que para esse elemento vamos apontar alguns detalhes:

Implementar no cluster
Alta disponibilidade, porque se você perder sua ” control plane ” isso irá impactar no seu ambiente de produção
As controllers irão prover ( VXLAN, MAC Table, ARP Table, VTEP Table )
Remove as dependências no multicast para a funcionalidade de VXLAN
Faz a implementação via NSX Manager, sem a necessidade de ter qualquer .ova
Controllers devem ser instaladas no mesmo vCenter que está registrado o NSX Manager, o qual devido a isso o vCenter deve gerenciar os hosts que estão rodando as controllers.

Com isso podemos concluir que após esse evento o próximo passo seja preparar os hosts, no qual irão instalar os modulos ( kernel ) nas maquinas físicas para que possamos evoluir posteriormente com os outros elementos que compõe essa solução.

Em nosso próximo post irei explicar um pouco sobre serviços de borda ( Edge Service ) e as menções sobre roteamento na borda e a segmentação do roteamento através do DLR.

Espero que tenham gostado e deixem seus comentários abaixo. 😛

Abs,
Rodrigo

VMware – Componentes do NSX – parte 2

Mon, 18 Jun 2018 00:00:00 +0000

Olá Pessoal,

Dando continuidade a nossa serie, gostaria de trazer mais alguns componentes que de fato vão compor a solução para utilização do NSX, ou seja, esses componentes são os ítens que são construídos no momento que você irá fazer a implementação dessa solução.

Para termos uma visão macro segue a estrutura para compor os ítens:

Aqui podemos observar a distribuição de todos os ítens, que consequemente vamos tratar entre camada física e lógica, que por sua vez automaticamente estão atrelados ao ” Data Plane ” , ” Control Plane ” , ” Management Plane ” e o ultimo chamado de ” Cloud Consumption “, onde não irei fazer muito tratativa nesse momento, pois esta mais atrelado ao NSX-T.

Data Plane:

O plano de dados do NSX é implementado pelo NSX vSwitch. O vSwitch no NSX para o vSphere é baseado no VDS, com alguns componentes adicionais. Os componentes complementares do NSX incluem módulos do kernel distribuídos como pacotes configuráveis de instalação do VMware ( VIBs ). Esses módulos são executados no hypervisor do kernel, fornecendo serviços incluindo roteamento distribuído, firewall distribuído e VXLAN para VLAN Bridging.

O NSX vSwitch permite o suporte para redes de ” overlay ” com o uso do protocolo VXLAN e a configuração de uma rede centralizada. O plano de dados também consiste em dispositivos de gateway que podem fornecer comunicação da rede lógica para a rede física ( por exemplo, VXLAN para VLAN ). Essa funcionalidade pode acontecer em L2 ( NSX bridging ) ou em L3 ( NSX roteamento ).

Control Plane:

O controlador NSX é uma parte essencial do plano de controle do NSX. Com o vSphere Distributed Switch ( VDS ), o controlador ativa VXLAN livre de multicast e a programação do plano de controle dos elementos, bem como, roteamento Lógico Distribuído ( DLR ).

O controlador NSX faz parte do plano de controle; é logicamente separado de todos os dados relacionados ao tráfego de comutação ( data plane ). Para melhorar ainda mais a alta disponibilidade e escalabilidade, o controlador NSX são implementados em um cluster de instâncias de números ímpares.

Além do controlador, a VM de controle fornece o plano de controle de roteamento, o qual permite o encaminhamento local no ESXi e também permite o roteamento dinâmico entre o ESXI, bem como o roteamento norte-sul ( Northbound – Southbound ) fornecido pelo Edge VM. É fundamental entender que os dados do plano de controle nunca vão atravessar o plano de dados.

Management Plane:

O NSX Manager é o plano de gerenciamento desse ecossistema. No NSX o gerenciador fornece configuração e orquestração de:

Componentes de rede lógicos – comutação lógica e roteamento
Serviços de rede e de borda
Serviços de segurança e firewall distribuído

Os serviços de borda e de segurança podem ser fornecidos por qualquer dos componentes que compõe NSX Manager, ou por fornecedores integrados à terceiros. O gerente NSX permite a orquestração perfeita de serviços internos e externos. Todos os serviços de segurança, sejam internos ou de terceiros, são implantados e configurados via o plano de gerenciamento do NSX.

Enfim, para que possamos reduzir um pouco sobre esse detalhamento segue abaixo as menções:

Em nosso próximo post vou detalhar alguns outros componentes dessa estrutura falando sobre o NSX Manager, NSX Controllers e os passos para essa implementação.

Abs,
Rodrigo

VMware – História do NSX – Parte 1

Thu, 14 Jun 2018 00:00:00 +0000

Olá Pessoal,

Gostaria de iniciar uma serie para explicar um pouco sobre esse produto da VMware que é chamado de NSX. A ideia dessa serie é tentar detalhar um pouco sobre as características dele e alguns caminhos que você pode utilizar para visualizar sua console, configurar e também fazer o deploy.

Acredito que nem todos saibam mas esse produto inicialmente foi desenvolvido pela NICIRA chamado de NVP ( Network Virtualization Plataform ), onde era uma empresa focada em um software definido para redes ( SDN ) e virtualização, a qual foi fundada em 2007 por Martin Casado, Nick McKeown and Scott Shenker. Baseado em seu desenvolvimento e interesse de mercado a empresa foi adquirida pela VMware em Agosto de 2012 agregando esse produto em seu portofolio trazendo no conceito de SDDC ( Software Defined Data Center ). Praticamente após 1 ano de aquisição desse produto a VMware lançou no mercado trazendo o nome de NSX, onde de fato trouxe para esse player uma demanda denominada aqui como ” Networking ” ou literalmente para a fatia de mercado intitulada como rede virtualizada.

Nos sabemos que VMware anteriormente tinha muito forte sua estrutura voltada especificamente para virtualização e atendendo muito bem a demanda dentro de ambientes de DC ( Data Center ), no qual agregava-se outros conceitos voltados para redes em seus parceiros, onde obviamente Cisco sempre foi uma grande aliada nesse setor, oferecendo soluções agregadas/compartilhadas a todo esse portfolio. Nesse momento vemos muitos confrontos de ” market share ” entre essas empresas devido a diferentes fatores que não irei detalhar nesse momento, mas que cada um pode fazer sua analogia e reflexão pessoal ( rsrs ).

Muito bem, voltando para o detalhamento dessa solução, eu gostaria de colocar alguns ítens, para que para os futuros posts possa ser melhor aproveitado falando-se em terminologia e acrônimos. Se você não viu meu post sobre essa sopa de letrinhas, vale a pena verificar ” Acrônimos do mercado atual “, e claro, devido esses termos vou detalhar voltado para nosso tema:

SDS – Software Defined Storage ( VMware VSAN, EMC ViPR )
SDC – Software Defined Compute ( VMware vSphere, Hyper-V )
SDN – Software Defined Network ( NSX, Contrail, ACI [ A Cisco não gosta de caracterizar como SDN devido ao DNAc ] )
SDDC – Software Defined Data Center ( Flexível, Provisionamento DC automatizado )

Com isso podemos agora mencionar sobre as versões que temos disponivéis para o mercado, onde tivemos algumas alterações para atendimento não somente de produtos VMware, mas devido agora este mundo onde precisa-se de multiplataformas, tendo a fisolofia que não pode atender apenas seu ” parquinho ” de equipamentos proprietários. Com isso posso trazer:

NSX-V – Somente atendido ao ambiente VMware ( vSphere )
NSX-mh – Multi-hypervisor utilizando multiplas images ( OpenStack, KVM, Kubernetes, ESXi, Hyper-V )

Você pode estar se perguntando, mh? Sim, anteriormente foi assim denominado e agora ele é chamado de NSX-T ( Transformers ). Pois bem, e o que muda entre essas versões?

Com o NSX-V, as organizações podem mobilizar a conectividade de rede entre máquinas virtuais e permitir que essas cargas de trabalho sejam conectadas de maneiras que, de outra forma, não poderiam ser entregues de forma eficiente pelo hardware de rede física. Na maioria das vezes, se você deseja executar uma infraestrutura de rede definida por software no âmbito do VMware vSphere, o NSX-V é a plataforma que você provavelmente usará.

Em contra-partida o NSX-T foi projetado para lidar com estruturas e arquiteturas de aplicativos emergentes, que possuem terminais heterogêneos e pilhas de tecnologia. Um dos principais casos de uso do NSX-T é com contêineres. Na virtualização de hoje, estamos vendo mais e mais aplicativos sendo executados em ambientes fora das máquinas virtuais.

O VMware NSX-T é integrado com o VMware Photon Platform, que é o sistema operacional centrado em nuvem que a VMware desenvolveu desde o início com os gostos do atual servidor vCenter em execução no topo dessa plataforma. O NSX-T também contém o plugin de interface de rede de contêiner ( CNI ) do NSX-T que permitirá aos desenvolvedores configurar a conectividade de rede para aplicativos de contêiner que ajudam a fornecer Infraestrutura como um Serviço.

Tivemos recentemente também atualização do NSX-T Datacenter que está co-relacionado ao NSX-Cloud, trazendo o conceito sobre MultiCloud com as integrações em AWS e Azure. Eu irei detalhar um pouco sobre essa demanda, mas deixarei para o final, pois gostaria de trazer alguns conceitos antes para que possamos chegar nessa estrutura. Se quiser conferir sobre o assunto, você já pode verificar através do anuncio do NSX-T Data Center.

Em nosso próximo post vou falar sobre o ítens que compõem o provisionamento do NSX ( Manager, Controllers, Edge, dLR, DFW, etc ).

Abs,
Rodrigo