Confira o artigo técnico escrito pelos colaboradores Adassa Lima e Matheus Arantes sobre Conectando On-Premises na AWS via Direct Connect. Confere lá!

Com a popularização da utilização dos serviços em Cloud, uma das maiores necessidades é fazer com que o ambiente On-Premises de uma empresa possa se conectar ao ambiente Nuvem. Com a finalidade de fazer um uso eficiente dos seus recursos. Pensando em alguns itens importantes nessa conectividade, temos a disponibilidade, o baixo custo, a velocidade de acesso à informação e a segurança dos dados.
Atualmente o uso desse acesso se dá através de um serviço baseado em internet chamado de VPN. Ele permite que, possamos manter uma conectividade entre a Cloud e o ambiente On-Premises conforme podemos ver no exemplo abaixo:

DESENHO 1 – CONECTIVIDADE CLOUD_ON-PREMISES VIA VPN

Utilizando esse método de conectividade, os dados que serão trafegados por essa tecnologia são criptografados e encaminhados via Link de Internet entre os ambientes. O que permite dizer que o tráfego está sendo enviado de forma segura. No entanto, a alta velocidade não é garantida, bem como a redundância. Já quando se trata dos links públicos da empresa, esses fatores são dependentes da qualidade do provedor que oferta essa conectividade, gerando uma certa dificuldade no gerenciamento e disponibilidade da informação via VPN.

Direct Connect

Para melhorarmos essa comunicação entre AWS Cloud e o On-Premises, a Amazon nos fornece uma opção de conectividade através de um serviço chamado Direct Connect. Ele utiliza uma conexão L2L via um Parceiro AWS (Links dedicados com a Equinix ou Tivit e compartilhado (hosted) com outras operadoras como Telium e Mundivox) para conectar esses ambientes, como se fosse uma extensão da rede interna do On-Premises para a AWS.
Conforme pode ser visto no desenho abaixo, provendo uma conexão dedicada, melhoramos o desempenho e aceleramos a transferência de dados com segurança e bom custo-benefício utilizando São Paulo e Rio de Janeiro como opções. Para locais mais afastados o custo pode ser maior.

DESENHO 2 – CONECTIVIDADE CLOUD_ON-PREMISES VIA DIRECT CONNECT

Basicamente, o Direct Connect é um link dedicado que conecta a AWS ao ambiente On-Premises. Após essa comunicação física estabelecida, as duas partes devem fazer o uso do protocolo dinâmico conhecido como BGP para estabelecer a sessão de divulgação dos blocos IPs, tanto da AWS quanto do ambiente On-Premises. Esse protocolo permite os filtros através das políticas de BGP que ajudam no bom funcionamento e gerenciamento do serviço.
Com esse modelo de conexão, que antes era utilizado para a comunicação via VPN, associamos o VGW, ou Virtual Private Gateway , ao Direct Connect. Assim o uso da VPN passa a ser redundante ao Direct Connect automaticamente através da prioridade do serviço pela AWS. Em caso de falha no serviço, a VPN assumirá o tráfego sem precisar de intervenção manual para o funcionamento, ou seja, aumentamos a disponibilidade, melhoramos a taxa de transferência, temos redundância na conectividade e mantemos a segurança do transporte da informação. Conforme mostra o desenho abaixo:

DESENHO 3 – CONECTIVIDADE CLOUD_ON-PREMISES VIA DIRECT CONNECT

Até então, esse cenário ainda é o mínimo requisitado para um bom uso do serviço de Direct Connect. Pois mantemos nossa redundância através da VPN, tendo como requisito para esse failover o uso da Internet. Todavia, para adotarmos as melhores práticas fornecidas pela AWS e no intuito de utilizar o serviço de forma mais eficiente e segura. É recomendado que o Direct Connect seja conectado entre AWS e On-Premises por duas conexões físicas distintas. Sendo, por exemplo uma conexão física entre AWS x Equinix-SP4 e uma outra AWS x TIVIT-SPO. Dessa forma temos uma redundância efetiva do serviço. Além de manter o mesmo padrão de funcionamento sem necessidade de acesso para a nuvem via Internet. Sendo assim, não só o desempenho, segurança e disponibilidade se mantém no mesmo nível. Como também, nesse caso, teremos resiliência:

DESENHO 4 – CONECTIVIDADE CLOUD_ON-PREMISES VIA DIRECT CONNECT REDUNDANTE

Como conclusão temos que, o Direct Connect é o serviço que aumenta não apenas a velocidade da sua conexão com a AWS. Consequentemente diminuindo a latência. Como também, se usado da maneira correta, proverá maior disponibilidade, resiliência, redundância e segurança da informação. Levando em consideração que no modelo de cobrança da AWS em cima de DTO (Data Transfer Out). Utilizando o serviço de Direct Connect a cobrança fica mais barata. Bem como o serviço se paga ao tempo de uso de dados que são utilizados por ele.

Laia mais textos técnicos escritos pelos colaboradores da Darede em nosso blog!

OUTRAS PUBLICAÇÕES

Blog-Darede-5-ferramentas-de-fluxograma

5 Ferramentas de fluxograma

Entenda quais são as principais ferramentas de fluxograma existentes no mercado e como elas podem auxiliar o mapeamento de seus processos!

Containers: o velho novo recurso de cloud

Os containers são uma boa opção para criar ambientes isolados que possuem todas as configurações e dependências necessárias para a execução de aplicações. Confira nosso artigo sobre esse conceito.

O que é o AWS DMS?

O que é AWS Database Migration Service (DMS)?  O AWS Database Migration Service (AWS DMS) é um serviço gerenciado da Amazon Web Services (AWS) que permite a replicação e migração de bancos de dados de forma fácil, segura e sem perda de dados. O DMS é compatível com migrações homogêneas, como de Oracle para o Amazon RDS for Oracle, e migrações heterogêneas (entre diferentes plataformas de banco de dados) como de Oracle ou Microsoft SQL Server para o Amazon Aurora.  Como o serviço funciona? Com o AWS DMS é possível optar por instâncias sob demanda ou utilizar a tecnologia sem servidor. O AWS Database Migration Service Serverless provisiona e gerencia a capacidade automaticamente.  Durante a migração as alterações realizadas no banco de dados de origem são replicadas continuamente no destino. Sendo assim,  o banco de dados de origem permanece operacional durante a migração, minimizando o tempo de inatividade de aplicações que dependem do banco de dados.   Após a conclusão da migração o banco de dados de destino permanece sincronizado com o de origem pelo tempo que for determinado, permitindo que a transição para o banco de dados ocorra no momento adequado.   O suporte é oferecido para diversos cenários, como: Do Oracle para o Amazon Aurora (compatível com MySQL), do MySQL para o Amazon Relational Database (RDS) para MySQL, do Microsoft SQL Server para o Amazon Aurora (compatível com PostgreSQL), do MongoDB para o Amazon DocumentDB (compatível com MongoDB), do Oracle para o Amazon Redshift e Amazon Simple Storage Service (S3). Principais componentes do AWS DMS  Instâncias de replicação: São máquinas virtuais EC2 que executam o software de replicação do DMS para extrair, transformar e carregar dados entre as origens e os destinos.   Endpoints: Representam as origens e destinos dos dados a serem migrados. Podem ser endpoints de banco de dados, como o Amazon RDS ou o Amazon Aurora; endpoints de armazenamento, como o Amazon S3; ou endpoints de mensagens, como o Amazon Kinesis.   Tarefas: São as configurações que definem a migração dos dados entre os endpoints. As tarefas especificam as tabelas a serem migradas, as transformações a serem aplicadas e outras opções de configuração.   Eventos: Permitem o monitoramento das tarefas e a captura de eventos relacionados à migração, como erros, conclusões, atualizações de status, entre outros.  Além disso, o AWS DMS inclui recursos como:   – AWS DMS Schema Conversion: Para converter esquemas e códigos-fonte;  – AWS DMS Serverless: Para provisionar, monitorar e ajustar automaticamente a escala de recursos de capacidade para uma migração com pouca intervenção humana.  Melhores práticas com o AWS DMS  É fundamental realizar uma análise detalhada das características do ambiente e das cargas de trabalho para definir a estratégia de migração mais adequada. Também é necessário um planejamento cuidadoso, incluindo a escolha dos endpoints corretos, a configuração das tarefas de migração e a definição de transformações de dados, se necessário.   Testes de migração em um ambiente propício são atividades relevantes antes de realizar a migração em produção. Assim, pode-se validar a funcionalidade dos dados e ajustar as configurações, caso se aplique.   Já durante a migração, monitorar as tarefas de migração e os eventos relacionados são fatores essenciais para a identificação de possíveis ocorrências e garantia no sucesso da migração. Billing e Free Tier  O AWS Database Migration Service (DMS) possui um modelo de pagamento baseado no uso. Os custos são calculados com base em fatores como o tipo e o tamanho das instâncias de replicação utilizadas, a quantidade de dados transferidos e a região da AWS selecionada para a migração.   Atualmente, o nível gratuito inclui até 750 horas de uso da instância Mono-AZ dms.t2.micro por mês durante um ano.   Na modalidade de instâncias sob demanda há um custo para as instâncias de replicação e por qualquer armazenamento de log adicional.   Thiago Marques Technical Account Manager thiago.marques@darede.com.br Technical Account Manager da Darede, formato em Rede de Computadores, e pós graduado em Segurança da Informação. Possui ampla experiência em Datacenters e Service Providers, além de ser um entusiasta em DevOps e mercado financeiro.

Office 365 ou Exchange Server?

Será que agora vou saber o que estou fazendo quando crio aquela entrada TXT, ou CNAME quando sigo um procedimento? Essa é uma pergunta que temos ouvido muito nos últimos anos. Uma empresa pretende migrar sua solução de e-mail e, frente às inúmeras soluções de e-mail existentes (OnPremises ou SaaS) para nessas duas finalistas: e agora? Adotar Microsoft Exchange ou Microsoft Office 365? Se você chegou até aqui, já deve saber bem o que é Microsoft Exchange Server e Microsoft Office 365. Caso tenha dúvidas, veja os links abaixo:   Microsoft Exchange Server     Microsoft Office 365   Como quase tudo em infraestrutura de TI, a resposta é: Depende! Fizemos um estudo onde colocamos todas as VARIÁVEIS possíveis e em nossa análise apresentamos alguns cenários possíveis onde podemos ver que para cada ambiente, há uma melhor solução. Abaixo, descrevemos cada uma dessas VARIÁVEIS, assim você conseguirá elencar as que fazem parte de sua realidade. 1) Quantidade de usuário Esse fator é muito importante, a primeira conclusão que devemos chegar é que o Custo Inicial de uma solução OnPremises, como é o Microsoft Exchange Server, é maior que o de uma solução SaaS, como o Office 365. Então, até aqui, nos parece que se você tem apenas um usuário, faz mais sentido utilizar o Office 365, as dúvidas agora seriam: a) Qual versão de Office365 usar e, b) A partir de quantos usuários/colaboradores valerá a pena usar o Microsoft Exchange Server (se é que valerá). 2) Investimento inicial Você possui recurso para um investimento inicial (CAPEX)? Se em seu orçamento tem sobrado recurso para investimento recorrente (OPEX), o uso de soluções SaaS pode lhe cair como uma luva. Já quando o contrário acontece, você tem uma grana sobrando para um projeto pontual, o uso de Exchange passa a ser possível. Mas não se esqueça de colocar em sua conta que sempre haverá um custo inicial, como para fazer a migração para o Office365. E mesmo usando o Exchange, haverá um custo recorrente para manter a solução, seja com profissionais internos ou contratando uma consultoria para administrar seu ambiente, além de energia, depreciação dos equipamentos, renovação de licenças e etc. 3) Uso do pacote Microsoft Office Essa é uma VARIÁVEL que tem feito a diferença em alguns cenários. O Office365 oferece, em todas suas versões, o direito dos usuários usarem o Pacote Office. Nos pacotes mais simples, apenas o Office Online (que, acreditem, tem atendido muitíssimos casos) e, a partir do pacote Bussiness dá o direito a usar o Pacote Offline, o mesmo já utilizado por nós enquanto tiver que pagar pelo serviço. 4) Estado atual e desejado de seu parque de licença Uma das sacadas da Microsoft é que com o uso do Office365, além de mudar a solução de e-mail de sua empresa, você pode utilizar o Pacote Office licenciado pagando por seu uso de forma mensal. Muitas empresas têm usado esse produto para substituir sua licença atual em versões antigas ou para regularização de seu parque. O Office365 traz junto a atualização permanente do Office, enquanto você manter o pacote mensal. Em outras palavras, você pode resolver um problema de softwares não regularizados e manter-se sempre na versão mais nova do Office. 5) Perfil de e-mails É muito importante considerar o perfil de e-mails da empresa. Por exemplo, se sua empresa tem um fluxo de e-mails grande entre os colaboradores, pode ser uma boa ideia usar o Exchange, pois os e-mails trafegariam somente na sua rede interna e não consomem o link de Internet. Elencamos aqui alguns perfis de empresa que podem exigir cenários específicos Fluxo de e-mails grandes: Se seu(s) link(s) de Internet são pequenos, certamente o uso de serviço externo pode ser um problema. Por exemplo, se você tem um link de 1,5,10Mbps certamente sua rede interna trafega em 100 ou 1000Mbps. Se seu servidor de e-mail estiver instalado dentro de seu escritório a experiência dos usuários com e-mail e com a Internet certamente será melhor. Legislações e Regras: Em alguns casos, como empresas do mercado financeiro ou instituições públicas, há regras específicas quanto o local e acesso a dados. Já tivemos casos onde não conseguíamos atender regras de retenção, ou o simples fato de a Microsoft ter acesso aos dados (mesmo que a política de uso do Office365 afirme o contrário), pois esses órgãos reguladores ou política de segurança interna não permitem o uso de solução em nuvem. Muitas Caixas de E-mail: A política de licenciamento do Office 365 é baseada em usuários, dessa forma cada caixa de e-mail requer uma licença. Algumas companhias utilizam diversas caixas de e-mail como: atendimento, compras, vendas (mesmo sabendo que isso poderia ser apenas um grupo ou poderíamos usar diretórios públicos). Nesse caso, o custo com Office 365 fica alto, enquanto no Exchange Server podemos criar quantas caixas de e-mail acharmos necessário sem custo inicial maior. Caixas de E-mail grandes: Os planos de Office 365, como seus concorrentes (Gmail, AWS WorkMail), possuem caixas de e-mail grande 50/100GB, o que costuma ser muito mais que o necessário e em ambiente OnPremises limitamos mais. 6) Infraestrutura Existente Caso você possua uma estrutura que atenda outros projetos, como cluster de hypervisor, storage com espaço disponível, co-location/locação de espaço em datacenter, etc., esse custo já existente pode ser utilizado para minimizar o custo inicial, já que, como veremos ao longo desses artigos, o custo com servidor, espaço, links de Internet é muito elevado. Abaixo, uma tabela comparativa para facilitar o entendimento das principais variáveis a serem pontuadas em sua decisão: Exchange Server Office 365 Custo por Mailbox Não Há Licença Mensal Custo por Usuário CAL Adquirida Pagamento Mensal Uso do Microsoft Office Adquirir Licença Incluso* Custo Inicial Elevado Baixo** Multiplataforma (Windows/Android/Iphone) Sim Sim Webmail Sim Sim Necessário Certificado SSL Sim Não *Office Offline apenas nos planos mais caros. ** É necessária equipe técnica para ativar e/ou migrar sua solução atual. Agora que nós já explicamos as principais diferenças e variáveis, sabemos que ambas as soluções são muito completas, mas com características distintas.

Nós usamos cookies para garantir e oferecer a melhor experiência de navegação em nosso site! Mais informações