IBM Virtual Router Appliance – Introdução

Introdução

O IBM Virtual Router Appliance (VRA) é um dispositivo de rede da IBM Cloud que utiliza o software Vyatta 5600 vRouter para oferecer os serviços:

• Firewall de trafego nas VLANs públicas
• NAT entre VLANs públicas e privadas
• VPN Site-to-Site
• Roteamento e Tunel GRE para links dedicados
• Suporte a multiplas VLANs

Casos de uso

Exemplo 1 – Servidores sem VRA

Neste primeiro caso foi criado dois servidores sem o VRA, e com isso os dois servidores tem acesso e são acessados pela rede pública e se comunicam pela rede privada.

Exemplo 2 – Servidores com a utilização de um VRA como Gateway entre o trafego de internet e os servidores.

Desta forma o VRA vira o defaul gateway das redes públicas e privadas selecionadas e pode aplicar regras de firewall, NAT, VPN, DMZ, Regras entre Zonas de segurança, etc.

 

Exemplo 3 – Utilização do VRA para estabelecer comunicação com links dedicados com sua empresa

O VRA além de acessos as VLANs públicas e privadas, ele tem acesso as VLANs de transito por onde chega a comunicação dos links dedicados. Com isso ele tem como criar regras de roteamento e canais de comunicação GRE com roteadores de sua empresa.

 

Conclusão

Existem vários casos de utilização que o VRA – Virtual Router Appliance é extremamente importante nas topologias de rede da IBM Cloud.

 

Terraform com IBM Cloud

Neste post vou explicar como realizar a integração da ferramenta de automação Terraform com a IBM Cloud.

O Terraform é uma ferramenta open source que permite voce criar ambientes a partir de código e pode ser integrado em várias plataformas de Cloud do mercado.

1 – Instalando o Terraform no MacOS (via terminal)

Eu vou realizar a instalação a partir do utilitário Homebrew
Passo 1 – Instalar o Homebrew (Caso já tenha instalado vá para o passo 2)

/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

Passo 2 – Instalação do Terraform

brew install terraform

2 – Baixar o pacote de configuração “terraform-provider-ibm”

Passo 1 – Download do arquivo darwin_amd64.zip no link:

https://github.com/IBM-Cloud/terraform-provider-ibm/releases

Passo 2 – Descompacte o arquivo na pasta Downloads

cd $HOME/Downloads
unzip darwin_amd64.zip

Criou um arquivo terraform-provider-ibm em sua pasta Download

Passo 3 – Crie uma pasta para os plug-in do terraform e copie o arquivo terraform-provider-ibm para esta pasta

mkdir -p $HOME/.terraform.d/plugins 
mv $HOME/Downloads/terraform-provider-ibm $HOME/.terraform.d/plugins/

3 – Preparando os arquivos de configuração do Terraform

Tem um exemplo de servidor LAMP para download em:

https://github.com/IBM-Cloud/LAMP-terraform-ibm

Passo 1 – Fazer uma cópia em seu computador

git clone https://github.com/IBM-Cloud/LAMP-terraform-ibm

Vai criar uma pasta em seu computador com os arquivos:

install.yml – Pacotes a serem instalados dentro do servidor, serviços e arquivos
provider.tf – Está especificando a “ibm” como provider
terraform.tfvars – Você deve adicionar seu Usuário e API da IBM Cloud (Softlayer)
vm.tf – Configuração da máquina virtual que você vai realizar o deploy.

Passo 2 – Verificando nome do usuário e API para colocar no arquivo terraform.tfvars
Account > Users > User List

Na lista de usuários você consegue ver o seu username e tem um link para ver sua API Key:

Passo 3 – No arquivo vm.tf voce deve atualizar a variável “ssh_key” pela sua chave de ssh local

Gerar uma chave:

ssh-keygen -t rsa

Copie a chave do arquivo:

cat $HOME/.ssh/id_rsa.pub

4 – Criando o servidor a partir de sua configuração Terraform

Passo 1 – Entra na pasta que você colocou seus arquivos:

 cd LAMP-terraform-ibm

Passo 2 – Iniciando o terraform para incluir as novas configurações

 terraform init

Passo 3 – Aplicar a configuração

 terraform apply

Passo 4 – Testar

Documentação sobre comandos e parâmetros do provider ibm se encontra em:

https://ibm-cloud.github.io/tf-ibm-docs/index.html

Acessando Object Storage (S3) no Linux

O Objetivo deste post é mostrar como que faz o acesso aos dados do IBM Cloud Object Storage (S3) no CentOS Linux.

Ferramenta utilizada: https://github.com/s3fs-fuse/s3fs-fuse
Sistema Operacional: CentOS 7
IBM Cloud Object Storage – S3 API (IaaS)

1. Instalando o s3fs no CentOS

Utilizando o usuário root:

# yum install epel-release

# yum install s3fs-fuse

Para informações de instalação em outras distribuições linux verificar a documentação no site da ferramenta

2. Criando um arquivo com as credenciais de acesso

Depois que você cria o seu repositório de Object Storage na IBM Cloud você clica em seu nome e depois em “Access & Permissions” para encontrar as seguintes informações:

• Access Key ID
• Secret Access Key

Com estes dados salvos você vai criar um arquivo de autenticação:

# echo ACCESS_KEY_ID:SECRET_ACCESS_KEY > ${HOME}/.passwd-s3fs

# chmod 600 ${HOME}/.passwd-s3fs

3. Mapeando seu Object Storage em uma pasta no CentOS Linux

Criar uma pasta para este mapeamento:

# mkdir /mnt/s3

Mapeando o seu “bucket” em seu filesystem local:

No portal da IBM Cloud você clica no seu repositório Object Storage (S3) nos menus “Manage Buckets” e “Access & Permissions” para as seguintes informações:

• Bucket Name: linux-blog
• Authentication Endpoints: s3.sao01.objectstorage.service.networklayer.com

Mapear seu Bucket na pasta criada:

# s3fs <buket-name> <pasta-local> -o url=https://<end-point> -o passwd_file=<arquivo-credenciais>

Ex:

# s3fs linux-blog /mnt/s3/ -o url=https://s3.sao01.objectstorage.service.networklayer.com -o passwd_file=${HOME}/.passwd-s3fs

Está mapeado o seu acesso a pasta do Object Storage no diretório /mnt/s3

Para validar que foi montado pode utilizar os comandos:

#df

# mount

Agora através da masta /mnt/s3 você pode manipular os arquivos.

Ubuntu – Configurar teclado americano com acentos pt-br (com cedilha)

Bom dia,

Eu instalei no meu PC o Ubuntu 16.04 em meu computador e tenho um teclado do modelo “Inglês Internacional” e assim que finalizou a instalação eu percebi que não funcionava os acentos.

Porque isso acontece?

– Quando você seleciona um teclado Americado(English) o instalador deixa o sistema em inglês e não instala os mapas de teclado, modulos do ambiente gráfico e configurações necessárias para o nosso idioma.

Como eu resolvi?

1 – Instala os pacotes do nosso idioma “Português (Brasil)”

Clique em “System Settings” => “Language Support” => “Install / Remove Languages…”

Selecione “Portuguese” e clique no botão “Apply”

Depois de instalado é necessário colocar o novo idioma como padrão, arrastando ele para o primeiro da lista:

Clicar em “Regional Formats” e selecionar os formatos de números, datas e moeda como “Português Brasil)

2 – Agora você configura o teclado

Clique em “System Settings” => “Keyboard” => “Text Entry”

Vai clicar no botão “+” e adicionar o modelo “English (US, alternative international)

3 – Reiniciar o computador.

Dicas: Após alguns dias trabalhando eu troquei o idioma para Inglês (US) dos menus e continuou funcionando os acentos do teclado.

Para Ubuntu 18.04 segue o passo a passo no arquivo:
https://cmazzer.files.wordpress.com/2019/01/teclado_us_acentos_ubuntu_18.04.pdf

Projeto de DR com Zerto e IBM Cloud

Atualmente é muito comum realizar projetos de DR (Disaster and Recovery) nos ambientes de produção para uma plataforma na nuvem. Vou descrever aqui como é feito um projeto utilizando a nuvem da IBM Bluemix e a ferramenta Zerto.

1 – Necessidade

Proteger um ambiente de servidores virtuais utilizando tecnologia VMware ou Microsoft do seu datacenter na nuvem

2 – Identificar os workloads

Um dos pontos principais de um projeto é identificar quais são os workloads que são críticos para sua empresa de realmente precisam fazer parte de um projeto de Disaster Recovery. Diferente de equipamentos já adquiridos e espaço ocioso em seu datacenter, na nuvem é cobrado por cada recurso que é utilizado. A capacidade de processamento, memória, disco e rede deve ser medida no detalhe.

3 – Ferramenta

Existem várias soluções que fazem backup, replicação de dados e orquestração/gestão de planos de contingência. Cada um com suas particularidades.

A ferramenta Zerto faz replicação contínua de máquinas virtuais organizadas em grupos de consistência para garantir que todos os workloads que tem afinidade façam pontos de recuperação iguais.

Pode ser feito a proteção de suas máquinas virtuais VMware ou Microsoft Hyper-v utilizando a mesma tecnologia no site de recuperação ou pode replicar entre as tecnologias diferentes. Ex. Site de produção Vmware e site de recuperação Hyper-v ou vice versa.

4 – Requisitos

Nos dois datacenters serão necessários

Para ambiente com até 750 máquinas virtuais e 5 sites:

1 x ZVM – Zerto Virtual Manager (Windows Server 2012 R2, 2 CPU, 4GB RAM, 4GB de disk)

1 x VRA – Virtual Replication Appliance por host físico (1 vCPU, 4GB RAM, 12GB disk)

Os dados de replicação contínua (Journal) fica armazenado no site destino das cópias e ocupa 7-10% de espaço adicional além das máquinas virtuais

A conectividade deve ser realizada por uma VPN site-to-site entre o datacenter on-premesis e o IBM Bluemix.

*A replicação não funciona com NAT de rede.

IBM Bluemix tem disponível 3 soluções VMware para realizar este projeto de DR

• VMware Cloud Foundation
• VMware vCenter Server
• VMware as a Service nos servidores Baremetal

https://www.ibm.com/cloud-computing/solutions/ibm-vmware/

5 – Rede

Você pode configurar para manter os mesmos endereços de rede ou especificar quais são os novos endereços que devem ter cada uma das máquinas virtuais

Para realizar um teste de Failover sem gerar conflito com ambiente produtivo deve ser configurada uma rede de testes a qual você possa acessar os sistemas e validar a funcionalidade dos mesmos.

6 – Conclusão

A Solução Zerto e IBM Bluemix é uma ótima forma de proteger em nuvem o seu ambiente de virtualização VMware ou Hyper-V. Em uma única solução tem as funcionalidades de replicação, alteração de endereços de rede, teste de failover, relatórios.

IBM Bluemix – Imagens de servidores virtuais

Neste post vamos explorar a funcionalidade de criar uma imagem de um servidor virtual da plataforma IBM Bluemix Infrastructure e criar um novo servidor a partir desta imagem.

1 – Criando imagens de servidores virtuais

Passo 1 – Procure na lista de devices o nome do servidor que deseja criar uma imagem e clique sobre o nome dele

Passo 2 – Na página “Device Details” abra o menu “Actions” e clique em “Create Image Template”

Passo 3 – Preencha os campos “Image Name”, selecione os discos que farão parte da imagem e selecione que aceita que seu servidor será desligado para realizar a imagem

2 – Verificando as imagens existentes

Passo 1 – Clique no menu “Devices” , “Manage” , “Images”

Passo 2 – Veja a lista de imagens salvas em sua conta

3 – Provisionando uma nova máquina a partir de sua imagem

Passo 1 – Clicar em “Actions” referente a sua imagem e selecione a compra por mês ou por hora.

Passo 2 – Siga o processo de compra normal de um servidor escolhendo as características de processador, memória, discos, rede.

Networking (redes) nos projetos de Disaster Recovery

Nos dias de hoje é muito comum empresas criar projetos de “Disaster Recovery”. E em muitos projetos é considerado copiar todos os dados de um datacenter para o outro e pronto. E no momento de ter acesso aos dados não funciona. Com o que devo me preocupar ?

Arquitetura de referência

Vou descrever alguns pontos muito importantes sobre Redes/Networking para os projetos.

1 – Endereço de rede (IP)

Utilizar outro datacenter normalmente implica em utilizar outros endereços de rede. Ou utilizar tecnologias que permitam a migração de um endereço de rede entre localidades.
A aplicação está preparada para trocar de endereço de rede? A maioria das aplicações e sistemas a resposta é não.
Quando se faz um backup ou replicação de uma máquina virtual, ela mantem todas as configurações inclusive endereço de rede. O datacenter o qual recebeu a replicação está preparado para utilizar o mesmo número ip?

2 – Distancia e latência entre os datacenters

Todas as tecnologias de replicação de dados e tempo de acesso as aplicações são de alguma maneira sensível a latência (tempo de resposta).
E a distancia entre os locais está diretamente relacionado com a latência. Nas tecnologias de fibra-ótica utilizada amplamente para comunicação de dados a cada 100km de distância você soma 1 milissegundo no tempo de resposta (Tempo de ida+volta da informação – RTT (Round Trip Time)). Lembrando que a conectividade entre as cidades nem sempre é uma linha reta, e nem todas as cidades se conectam diretamente as outras, esta conta pode variar.

3 – Largura de banda

Saber exatamente a quantidade de banda de rede necessária para manter um ambiente replicado / disponível também é uma tarefa muito difícil por que precisa conhecer algumas informações de utilização de rede, que geralmente quem tem um datacenter local não mede de forma granular a utilização interna de sua rede. Por exemplo, a quantidade de trafego gerado para fazer um backup.

4 – Segurança

Segurança de redes é você proteger seus dados para que somente pessoas autorizadas tenham acesso a ela. Com isso é necessário se preocupar no ambiente de disaster recovery com os mesmos pontos sobre arquitetura de redes que o ambiente principal. Endereços de rede, Firewall, IPS/IDS, autenticação, patchs, etc.

5 – Conectividade de acesso

Hoje como as pessoas acessam os sistemas? Via rede local? Vpn? Internet?
Então no caso de indisponibilidade do seu datacenter principal, o qual vai ficar também indisponível todos os equipamentos de rede de dentro dele. Como será a conectividade com o outro datacenter?
Isso é importantíssimo porque participo de vários projetos que a empresa quer somente utilizar um link direto entre os dois datacenters para uma replicação de dados e não se preocupa com o acesso do usuário aos sistemas. E do que adianta um sistema replicado sem acesso ao usuário quando precisa?

Conclusão

Para o sucesso do seu projeto de Disaster Recovery, é necessário realizar um projeto de rede completo. E também validar o comportamento das aplicações quando estiver em outro datacenter.

VMware – Virtual SAN

O VMware Virtual SAN é a tecnologia de “Software Defined Storage” da VMware que é integrada com o hypervisor e utiliza os discos dos hosts para o serviço de armazenamento virtual. Em muitos casos substituindo os tradicionais Storages arrays em sua solução de virtualização de servidores e desktops (VDI).

O armazenamento é separado em duas áreas

• Área de cache
  • Discos SSD/Flash de grande duração e baixa capacidade de armazenamento
• Área de capacity
  • Discos SSD/Flash, SAS ou SATA de baixa duração e grande capacidade de armazenamento

Modos do vSAN

• Hybrid (SSD + HDD) – Neste caso toda leitura (Read Cache ocupa 70% da capacidade) e gravação (Write Buffer ocupa 30% da capacidade) é realizada nos discos de cache SSD e depois armazenados na área de capacity HDD.
• All-Flash (SSD Only) – Neste cado toda leitura é realizada direto da área de capacity e escrita na área de cache. As configurações All-Flash suportam performance até 100.000 IOPS por cluster.

Funcionalidades

• Desduplicação e Compressão
  • São funcionalidades presentes somente no modo All-Flash
• Storage Polices
  • É possível criar políticas para atender máquinas virtuais ou grupos de máquinas virtuais baseado em
    • Tolerancia de falhas
    • SLA
    • Qualidade de serviço
    • Performance (IOPS Limits)
• Scale-Out
  • O crescimento de capacidade e performance é realizado adicionando novos hosts com a mesma configuração de discos. Suporte até 64 hosts por cluster.
• Health and Performance Monitoring
  • Ferramenta de monitoramento que informa várias métricas de performance
    • Throughput
    • IOPS
    • Latency
    • Informação por cluster, host, máquina virtual ou disco virtual

Requisitos mínimos

• 3 Hosts ESXi
• Modo Hybrid
  • 1 SSD + 1 HDD
  • Ethernet 1Gbps
• Modo All-Flash
  • 2 SSD
  • Ethernet 10Gbps
• Interface VMKernel habilitada para vSAN
• Controladora de Storage SAS, SATA ou Controladoras RAID configuradas nos modos:
  • Pass-through ou RAID 0
  •  Cache e controles avançados desligados. Se não tiver como desligar o cache de leitura deve ser configurado como 100%
• Memória RAM
  • 32GB de memória RAM são necessários para gerenciar a capacidade máxima de 5 disk groups com 7 discos de capacity por disk group.
• CPU
  • Aproximadamente 10% do processador do host é utilizado para suportar o vSAN

 

Hardware Homologado

Para utilização do Virtual SAN é necessário utilizar hardware homologado. Os componentes que fazem parte da homologação são:

• Caching Device
• Capacity Device
• Storage Controler

Estes dados podem ser encontrados no site da VMware Compatibility Guide:
http://www.vmware.com/resources/compatibility/search.php?deviceCategory=vsan

Sizing

O Sizing adequado deverá ser realizado de acordo com os requisitos do ambiente, e pode utilizar a ferramenta da VMware para suporte:
https://vsantco.vmware.com/

API

O Virtual SAN tem seu “control plane” com API públicas para suporte de gerenciamento e automação de tarefas com as ferramentas:

• VMware vRealize Automation
• VMware vSphere PowerCLI
• VMware Integrated Openstack

 

Vídeo configurando Virtual SAN por @itirohidaka