AWS Well-Architected

19 de março de 2021 Deixe um comentário

Estudando sobre tecnologias AWS, um dos principais recursos de capacidade e estudo que encontrei foi o AWS Well-Architected.

O AWS Well-Architect tem por objetivo, ajudar arquitetos de nuvem a entender como criar ambientes de infraestruturas seguras, resilientes, eficientes e de alta performance para aplicações e cargas de trabalho.

Um dos pontos que me chamou a atenção é o fato de ser baseado em cinco pilares:

  1. Excelência operacional
  2. Segurança
  3. Confiabilidade
  4. Eficiência de performance
  5. Otimização de custo

Fornece uma abordagem consistente para avaliar arquiteturas e implementar cenários que podem se expandir com o tempo.

O AWS Well-Architected Framework começou como um único whitepaper, mas foi expandido para incluir perspectivas específicas de domínios.

Acessem os laboratórios práticos e a AWS Well-Architected Tool.

A AWS WA Tool, disponível gratuitamente no Console de Gerenciamento da AWS, fornece um mecanismo para avaliar regularmente suas cargas de trabalho, identificar problemas de alto risco e registrar suas melhorias.  

Indico também o blog https://aws.amazon.com/pt/blogs/architecture/.

Regiões e zonas de disponibilidade Alibaba Cloud

4 de janeiro de 2021 Deixe um comentário

Olá pessoal, tudo bem?

Alguns profissionais têm me perguntado sobre as regiões e zonas de disponibilidade da nuvem Alibaba. Hoje, vamos falar sobre esse tópico e sobre lista completa de regiões e zonas do Alibaba Cloud.

Primeiro, vamos falar sobre o que são Regiões:

Uma região basicamente é uma área geográfica, com um data center. Uma região reúne recursos da Nuvem Alibaba e pode ser alterada após a criação do recurso. A tabela a seguir descreve as informações sobre todas as regiões do Alibaba Cloud, incluindo os IDs de região e as cidades onde as regiões residem.

Regiões na China continental (Note que há mais regiões na China do que em outros lugares ou país, por motivos óbvios):

RegiãoCidadeRegião IDNúmero de zonas
China (Qingdao)Qingdaocn-qingdao2  
China (Pequim)Pequimcn-pequim8  
China (Zhangjiakou)Zhangjiakoucn-zhangjiakou3  
China (Hohhot)Hohhotcn-huhehaote2  
China (Ulanqab)Ulanqabcn-wulanchabu2  
China (Hangzhou)Hangzhoucn-hangzhou8  
China (Xangai)Xangaicn-shanghai7  
China (Shenzhen)Shenzhencn-shenzhen5  
China (Heyuan)Heyuancn-heyuan2  
China (Guangzhou)Guangzhoucn-guangzhou2  
China (Chengdu)Chengducn-chengdu2  

Obs.: Destaque para as regiões de Pequim, Hangshou e Xangai, com 8 zonas de disponibilidade, 8 zonas de disponibilidade e 7 zonas de disponibilidade, respectivamente.

Região fora da China continental (Mesmo Hong Kong sendo na China Continental, por questões de administração, a região de Hong Kong é tratado como fora da China Continental).

As regiões na China Continental, são recomendados para quando precisamos usar uma região que seja a mais próxima da localização geográfica de seus clientes/usuários-alvo para acelerar o acesso. No entanto, vale ressaltar que, em termos de infraestrutura de rede, qualidade de rede do Border Gateway Protocol (BGP), qualidade de serviço (QoS) e facilidade de uso e configuração em instâncias do Elastic Compute Service (ECS), as regiões do Alibaba Cloud na China continental são semelhante.

RegiãoCidadeRegião IDNúmero de zonas
China (Hong Kong)Hong Kongcn-hongkong2  
Cingapura (Cingapura)Cingapuraap-sudeste-13  
Austrália (Sydney)Sydneyap-sudeste-22  
Malásia (Kuala Lumpur)Kuala Lumpurap-sudeste-32  
Indonésia (Jacarta)Jacartaap-sudeste-52  
Índia (Mumbai)Mumbaiap-south-12  
Japão (Tóquio)Tóquioap-Nordeste-12  
US (Silicon Valley)Silicon Valleyus-west-12  
US (Virginia)Virginiaus-east-12  
Alemanha (Frankfurt)Frankfurteu-central-12  
Reino Unido (Londres)Londreseu-west-12  
Emirados Árabes Unidos (Dubai)Dubaime-east-11  

Obs.: Os datacenters e as regiões que se destacam são US (Silicon Valley), US (Virginia), Alemanha (Frankurt) e Reino Unido (Londres).

Ainda falando em regiões, elas são completamente independentes, enquanto as zonas estão completamente isoladas, no entanto, zonas na mesma região podem ser conectadas com links de baixa latência.

Legal! E o que devo fazer quando seleciono uma região?

Bem, quando selecionar uma região, temos que considerar os seguintes fatores:

  • Localização geográfica
  • Selecione uma região com base na localização geográfica e em você e seus usuários-alvo.

As regiões fora da China Continental, podem ser destinadas a clientes localizados na China (Hong Kong) ou no Sudeste Asiático, você pode selecionar as seguintes regiões: China (Hong Kong), Cingapura (Cingapura), Malásia (Kuala Lumpur) e Indonésia (Jacarta).

Ou seja, podemos avaliar o uso de regiões de acordo com a proximidade dos clientes. Por exemplo:

  1. Meus clientes estão localizados no Japão ou mesmo na Coréia do Sul, nesse caso podemos selecionar a região Japão (Tóquio).
  2. Meus clientes estão na Índia, vamos selecionar a região Índia (Mumbai).
  3. Meus clientes estão na Austrália, escolheremos a região Austrália (Sydney)
  4. E se meus clientes estiverem nos EUA? Podemos selecionar as regiões dos EUA (Vale do Silício) e EUA (Virgínia). Podemos pensar nessa opção para os clientes no Brasil.
  5. Os clientes estão localizados na Europa Continental, selecionaremos a região Alemanha (Frankfurt).
  6. E se estiverem no Oriente Médio, podemos selecionar a região dos Emirados Árabes Unidos (Dubai).

Interessante, não é?

E o que são Zonas? Uma zona é uma área física com grades e redes de energia independentes em uma região. A latência de rede para acesso entre instâncias na mesma zona é menor. As zonas dentro da mesma região têm acesso umas às outras, mas as falhas em uma única zona não afetarão as outras, reduzindo possíveis problemas.

É recomendado escolher um método de implantação com base em seus requisitos de negócios para recuperação de desastres e latência de rede.

Se o seu aplicativo ou solução requer recursos de alta recuperação de desastres, recomenda-se que escolha a implantação de várias zonas.

Vamos falar de Azure VMware Solutions?

30 de dezembro de 2020 Deixe um comentário

A Microsoft e a VMware há algum tempo, estabeleceram uma parceria visando permitir aos clientes acelerar sua transformação digital. Pensando nisso, a VMware e a Microsoft criam integrações de soluções inovadoras que aprimoram a experiência e a produtividade dos usuários. Essa aliança, traz um portfólio de ofertas da VMware, incluindo nuvem híbrida, modernização de aplicativos, segurança, integração de rede de nuvem virtual e espaço de trabalho digital, o que permite aos clientes maximizarem os investimentos existentes e futuros com ambas as empresas.

A ideia do Azure VMware Solution é ter uma solução validada pela VMware, com validação e testes de aprimoramentos e atualizações, onde a Microsoft gerencia e mantém o software e a infraestrutura de nuvem privada. Isso permite que possamos nos concentrar no desenvolvimento e na execução de cargas de trabalho nas nuvens privadas.

Estamos falando de fornecer nuvens privadas com clusters vSphere, criados com base na infraestrutura bare-metal dedicada do Azure, com implantação mínima com hosts, e podendo adicionar mais hosts, até 16 hosts por cluster. 

Todas essas nuvens privadas provisionadas contêm o vCenter Server, o vSAN, o vSphere e o NSX-T (Ambiente de hiper convergência), onde podemos migrar cargas de trabalho dos ambientes locais, implantar novas VMs (máquinas virtuais) e consumir os serviços do Azure nas suas nuvens privadas.

Podemos mover as cargas de trabalho baseadas em VMware localizadas no datacenter para o Azure e integre seu ambiente local com a nuvem Microsoft. Podemos continuar gerenciar os ambientes existentes com as mesmas ferramentas do VMware, modernizando seus aplicativos com os serviços nativos do Azure.

Outro cenário é a possibilidade de mover suas cargas de trabalho VMware com facilidade para o Azure garantindo a produtividade com elasticidade, escala e ciclos de provisionamento rápidos.

Nesse caso, podemos exibir e criar VMs do vSphere no portal do Azure por meio de CLI ou de chamadas à API, automatize implantações e habilite o logon único.

Ponto importante: Como garantir acesso à capacidade adicional sob demanda, desativar ou expandir datacenters existentes? Mudando para a nuvem, nesse caso Microsoft Azure, de maneira fácil e com uso de tecnologias HCX da VMware.

Vou falar mais a frente, em outro artigo, sobre a integração e configuração do Azure VMware Solution.

Diferenças entre Azure Stack HCI e Azure Stack Hub

30 de dezembro de 2020 Deixe um comentário

No começo dos meus estudos sobre Azure Stack, falando com um amigo, ele perguntou: Qual Azure Stack? Pode parecer simples, mas na verdade, precisamos esclarecer alguns pontos e, vamos definir nesse artigo, as diferenças entre Azure Stack Hub e Azure Stack HCI.

Vamos começar pelo meu preferido: Azure Stack HCI.

Basicamente, o Azure Stack HCI é destinado a clusters locais que executam cargas de trabalho virtualizadas, e com conexões de nuvem híbrida integradas, e que podemos entregar como um serviço do Azure, (onde será cobrado através de uma assinatura do Azure). Também inclui a capacidade de hospedar o serviço Azure Kubernetes.

Resumindo, estamos falando de uma solução de cluster de infraestrutura hiperconvergente (ou HCI – Hyper Converged Infrastructure), onde podemos hospedar cargas de trabalho virtualizadas do Windows e Linux, com armazenamento em um ambiente híbrido local. Nesse cenário, os serviços híbridos do Azure visam aprimorar o cluster com recursos como:

  • Monitoramento baseado em nuvem;
  • Recuperação de site e backups de VM;
  • Visualização centralizada das implantações de Azure Stack HCI no portal do Azure;
  • Gerenciamento do cluster usando ferramentas existentes, incluindo o Windows Admin Center e o PowerShell.

Ok! Agora vamos entender o que o Azure Stack Hub

Bem, nesse caso, estamos falando de uma extensão do Microsoft Azure, onde fornece uma maneira de executar aplicativos em um ambiente local trazendo a experiência e disponibilidade de serviços do Microsoft Azure em seu datacenter, usando uma plataforma unificada de nuvem consistente, permitindo as empresas tomar decisões de tecnologia com segurança, obedecendo seus requisitos de negócios, em vez de decisões de negócios com base nas limitações da tecnologia.

Parece estranho não é mesmo? Pode parecer que estamos falando das mesmas coisas, mas acredite, estamos falando de situações distintas onde o Stack Hub é uma extensão do Azure e o Stack HCI é uma solução hiper convergente que pode se estender para o Azure.

Ok! Quando devo e porque usar o Azure Stack Hub?

Sabemos que o Azure é uma plataforma de nuvem com milhares de recursos, disponibilizados para que os desenvolvedores criem aplicativos modernos, utilizem recursos de monitoramento, ambientes serveless, entre outros. Mas, alguns aplicativos baseados em nuvem ou criados para utilizarem a nuvem, podem enfrentar obstáculos como latência, conectividade intermitente e até mesmo respeitar regulamentações. É aí, que o Azure e o Azure Stack Hub podem desbloquear e criar casos de uso de nuvem híbrida para aplicativos voltados para o cliente e de linha de negócios internos.

E quando usar o Azure Stack HCI?

O Azure Stack HCI, vem fornecer funcionalidades que não estão presentes no Windows Server. Estamos falando de situações como capacidade de usar o Windows Admin Center para criar um cluster hiperconvergente que usa Storage Spaces Direct para um armazenamento de preço-desempenho superior. O sistema operacional (se podemos chamar assim!) Azure Stack HCI é executado em hardware validado (Homologado e suportado pela Microsoft, para evitar problemas. Imaginem, alguém pegar um hardware qualquer e instalar a solução e ver que não está funcionando corretamente!), e se conecta ao Azure e assim, habilita recursos disponíveis no ambiente de nuvem. Estamos falando inclusive de possibilidade de estender o cluster entre sites para ter um failover automático entre sites.

Imaginem os seguintes cenários:

Ter soluções de ponta que tragam os requisitos de latência e conectividade processando dados localmente no Azure Stack Hub. Imaginem também, ter algo que agregue recursos diversos no Azure para análises adicionais, com lógica de aplicativo por exemplo. Nesse caso, podemos implantar o Azure Stack Hub desconectado da Internet sem conectividade com o Azure. Esse é um cenário possível em grandes indústrias e fábricas, navios petroleiros e de gás ou mesmo perfuração de poços e minas diversas.

Usar aplicativos em nuvem que atendam e obedeçam a regulamentações variadas, onde possamos desenvolver e implantar aplicativos no Azure garantido flexibilidade para implantar no ambiente local (on premises) usando o Azure Stack Hub para atender aos requisitos de regulamentação, regras ou de políticas. Nesse caso, não será necessário fazer nenhum tipo de mudança de código será necessária.

Uso de modelo de aplicativo em nuvem local (Ou ambiente local), onde podemos usar os serviços do Microsoft Azure, uso de contêineres, uso de arquiteturas serverless e micro serviços que visam atualizar e estender aplicativos pré-existentes ou criar novos aplicativos. Podemos usar processos DevOps no Azure, ou seja, na nuvem e também, no Azure Stack Hub (no local/on premises) visando acelerar a modernização desses aplicativos tornando-os aplicativos essenciais de missão crítica.

E com relação ao uso de Azure Stack HCI?

Podemos mencionar alguns casos de uso para Azure Stack HCI, mesmo que não seja destinado a cargas de trabalho não virtualizadas, onde podemos Azure Stack HCI nos seguintes cenários:

  1. Consolidação e modernização do data center: Iniciei um artigo, aqui no blog falando sobre esse tema. Estamos falando sobre como atualizar e consolidar hosts de virtualização antigos com Azure Stack HCI, onde podemos melhorar o ambiente, garantir a escalabilidade e tornar mais fácil de gerenciar e também proteger.

Nesse cenário, estamos tratando de uma oportunidade de “aposentar” ou descomissionar um hardware de armazenamento legado (por exemplo), visando reduzir o espaço ocupado e assim reduzir também o custo total de propriedade (TCO).

A administração das operações e dos sistemas será mais simplificada com ferramentas e interfaces unificadas.

  • Cargas de trabalho virtualizadas de alto desempenho: Usar o Azure Stack HCI para esse cenário, pode fornecer o melhor desempenho por exemplo para bancos de dados SQL Server e outras cargas de trabalho sensíveis ao desempenho que exigem milhões de IOPS de armazenamento ou transações de banco de dados por segundo. Com isso, podemos oferecer latência consistente mais baixa com o uso discos SSDs padrão NVMe.
  • Escritórios remotos (Branch Office) e filiais: Um dos cenários mais incomuns. Estamos tratando de utilizar soluções de cluster de dois (ou mais) servidores usando o Azure Stack HCI, com o objetivo de modernizar a infraestrutura seja para escritórios remotos e filiais, lojas de varejo (outro ambiente muito comum no Brasil) e locais como fazendas por exemplo.
  • Desktops virtuais: Nesse momento de pandemia, muitos clientes buscaram soluções de desktops virtuais, onde muitas empresas hospedam desktops virtuais no ambiente local para baixa latência e garantia de gestão de dados.

Nos próximos artigos, vamos detalhar mais sobre o Stack Hub e o Stack HCI!

O que é RAM (Ou Resource Access Management)

30 de dezembro de 2020 Deixe um comentário

Para começar, não estamos falando de memória RAM, mas sim de um serviço fornecido pela Alibaba Cloud, que permite gerenciar identidades de usuários e permissões de acesso a recursos.

O RAM permite o gerenciamento de identidades em uma conta do Alibaba Cloud e concede diversas permissões a uma única identidade ou a um grupo de identidades. Com isso, podemos autorizar diferentes identidades para acessar diferentes recursos do Alibaba Cloud.

O RAM possui os seguintes recursos:

  • Gerenciamento de usuários do RAM e seus pares de AccessKey. Podemos também pode habilitar a autenticação multifator (MFA) para usuários do RAM.
  • Gerenciamento das permissões dos usuários do RAM para acessar os recursos do Alibaba Cloud.
  • Gerenciamento de canais de acesso a recursos. Isso garante que os usuários do RAM possam acessar recursos específicos do Alibaba Cloud usando canais seguros no horário especificado e a partir dos endereços IP especificados.
  • Gerenciamento de instâncias e dados criados por usuários do RAM. Para uma empresa, o RAM garante que as instâncias e os dados criados pelos usuários ainda estejam disponíveis, mesmo que os usuários deixem a empresa.
  • Usar serviços de logon único (SSO). O Alibaba Cloud oferece dois tipos de serviço SSO para provedores de identidade (IdPs): SSO baseado em usuário e SSO baseado em função.

Os principais cenários de uso são:

  • Uso do RAM para gerenciar permissões e recursos do usuário: Quando uma empresa deseja migrar um projeto para o Alibaba Cloud. Imagine que ela adquiriu vários tipos de recursos do Alibaba Cloud, como instâncias do Elastic Compute Service (ECS), ApsaraDB para instâncias RDS, instâncias do Server Load Balancer (SLB) e buckets do Object Storage Service (OSS). Funcionários específicos são necessários para gerenciar esses recursos de nuvem. Funcionários diferentes requerem permissões diferentes para cumprir suas funções.
  • Uso de token STS para autorizar um aplicativo móvel acessar os recursos do Alibaba Cloud: Quando uma empresa desenvolveu um aplicativo móvel e comprou o serviço OSS. Nesse caso, o aplicativo móvel é executado, obviamente, em dispositivos móveis. Tais dispositivos podem s não ser controlados pela empresa. Nesse caso, a empresa deve conceder as permissões necessárias ao aplicativo móvel. O aplicativo móvel pode então fazer upload e download de dados do OSS.
  • Uso de uma função RAM para conceder permissões nas contas do Alibaba Cloud: Quando uma empresa (Empresa A) comprou vários tipos de recursos do Alibaba Cloud, (como instâncias ECS, instâncias RDS, instâncias SLB e buckets OSS), e deseja autorizar outra empresa (Empresa B) a acessar recursos especificados adquiridos pela Empresa A.
  • Uso do RAM para autorizar aplicativos a acessar os recursos da Nuvem Alibaba: Nesse caso, uma empresa adquiriu instâncias do ECS e deseja implantar seus aplicativos nessas instâncias do ECS. Esses aplicativos precisam usar pares AccessKey para chamar operações de API de outros serviços do Alibaba Cloud.

Os principais Benefícios de uso do RAM são:

  1. Permitir criar e gerenciar usuários de RAM para funcionários, sistemas, aplicativos e outras identidades.
  2. Gerenciar as permissões dos usuários de RAM para acessar os recursos do Alibaba Cloud.
  3. Permitir manter a conta e senha do Alibaba Cloud estritamente confidenciais quando há vários usuários em uma empresa que precisam gerenciar recursos de nuvem de forma colaborativa.
  4. Permitir a concessão aos usuários para permissões mínimas necessárias para garantir alta segurança.

Criando um host dedicado ou DDH

30 de dezembro de 2020 Deixe um comentário

Já falamos aqui sobre o que é um Dedicated Host (DDH), agora vamos descrever como criar um host dedicado de assinatura usando o console do Elastic Compute Service (ECS).

Primeiro os pré-requisitos:

  • Uma conta Alibaba Cloud é criada. Leia Criar uma conta Alibaba Cloud.
  • Um cartão de crédito ou conta do PayPal está associado à sua conta do Alibaba Cloud.

Agora o passo a passo do procedimento:

  1. Faça logon no console do ECS.
  2. No painel de navegação esquerdo, escolha Instances & Images, depois clique em Dedicated Hosts.
  3. Na barra de navegação superior, selecione uma região.
  4. Na página Dedicated Hosts, clique em Create DDH.
  5. Na página que aparece, defina os seguintes parâmetros:
  6. Billing Method (Método de cobrança): Selecione Subscription (Assinatura).
  7. Region: Selecione uma região e uma zona onde deseja criar um host dedicado.

Por exemplo, para criar um host dedicado na região da China (Beijing/Pequim), selecione China (Beijing) na lista suspensa.

  • Dedicated Host Type, DDH Name e Quantity (Quantidade): selecione um tipo de host dedicado, insira um nome de host dedicado e, a seguir, especifique o número de hosts dedicados que deseja adquirir.

O tipo de host dedicado determina a família de instâncias e o número máximo de instâncias do ECS que você pode implantar no host dedicado. Os tipos de host g6s, c6s e r6s permitem que você personalize a proporção de vCPU para memória. Isso permite alocar recursos de computação de maneira flexível ao criar instâncias do ECS.

Importante: Observe que as instâncias do ECS em hosts dedicados SSD i2 locais não oferecem suporte à migração manual e failover automático. Se um host dedicado SSD i2 local falhar, nesse caso podemos abrir um tíquete para solicitar a migração manual. Mas, os dados nos discos locais serão perdidos após a migração. Cuidado!

  • Opcional: adicione tags.

Você pode atribuir tags a hosts dedicados e gerenciá-los em grupos.

  • Opcional: Selecione um grupo de recursos.

Você pode separar hosts dedicados em grupos de recursos diferentes e definir permissões de acesso diferentes para esses hosts dedicados.

  • Na seção DDH Setting, defina os seguintes parâmetros.
ParâmetroDescrição
Allow Automatic Deployment (Permitir implantação automática)Se você selecionar Allow Automatic Deployment, as instâncias do ECS serão implantadas automaticamente nos hosts dedicados disponíveis. Se você não selecionar Allow Automatic Deployment, deverá especificar um host dedicado ao criar uma instância do ECS. A opção Allow Automatic Deployment é selecionada por padrão.
Automatic Instance Migration upon DDH Failure (Migração de instância automática após falha de DDH)Se você selecionar Automatic Instance Migration upon DDH Failure, as instâncias do ECS em um host dedicado serão migradas automaticamente para outro host dedicado se o host dedicado original falhar.Se você não selecionar esta opção, deverá enviar um tíquete para solicitar um novo host dedicado se o host dedicado original falhar. Essa opção é selecionada por padrão. Podemos modificar essa configuração após a criação do host dedicado. Aviso Esta opção não está disponível para hosts locais SSD i2 dedicados.
CPU Oversold Ratio (Taxa de sobre-venda de CPU)A opção CPU Oversold Ratio afeta o número de vCPUs disponíveis em um host dedicado. Você pode usar a seguinte fórmula para calcular o número de vCPUs disponíveis em um host dedicado: Número de vCPUs disponíveis = Número de núcleos físicos da CPU × 2 × taxa de overcommit da CPU. Em cenários onde a alta estabilidade da CPU não é necessária, como ambientes de desenvolvimento e teste, você pode aumentar o número de vCPUs disponíveis em um host dedicado aumentando a taxa de overcommit da CPU. Dessa forma, podemos implantar mais instâncias do ECS da mesma especificação no host dedicado e reduzir o custo de implantação da unidade. Aviso Podemos configurar taxas de overcommit o da CPU apenas para os seguintes tipos de host dedicados: g6s, c6s e r6s. Por exemplo, o número de núcleos físicos de CPU em cada host dedicado g6s é 52. Se definirmos a taxa de overcommit de CPU de um host dedicado g6s para 4, o número de vCPUs disponíveis no host dedicado é 416.
  • Defina Duration (Duração) do parâmetro e selecione a opção Enable Auto-renewal obedecendo seus requisitos de negócios.
  • Leia e concorde com os Dedicated Host Terms of Service.
  • No canto inferior direito, confirme o custo ao lado de Total e clique em Preview (Visualizar).
  • Na caixa de diálogo Preview, confirme as configurações e clique em Create Order (Criar pedido).
  • Na página que aparece, siga as instruções para concluir o pagamento.

Pronto! Agora podemos visualizar o host dedicado criado na página Hosts dedicados. Se o host dedicado estiver no estado Running, já podemos usá-lo. Caso o host dedicado criado não aparecer na página Hosts dedicados, aguarde e atualize a página.

Conceitos básicos sobre Host Dedicated (DDH)

30 de dezembro de 2020 Deixe um comentário

Neste artigo, vamos apresentar os conceitos básicos sobre Host Dedicado (DDH).

Host dedicado (Ou Dedicated Host): Um host em nuvem com recursos físicos dedicados. Os recursos no servidor físico são exclusivos para um locatário. O host dedicado é isolado de outros locatários no nível da máquina física. Falamos sobre isso em outro artigo.

Locatário (Ou Tenant): Uma conta do Alibaba Cloud permite várias contas de usuário RAM e tem permissões totais para usar todos os recursos físicos dos hosts dedicados. Vamos falar mais a frente sobre o que é.

Tipos de host dedicado: As especificações de um host dedicado incluem o modelo físico da CPU, número de núcleos, número de CPUs (número de soquetes), armazenamento local, número de CPUs virtuais (vCPUs) e memória. Você pode selecionar um tipo de host dedicado com base em sua família de instâncias ECS compatível. As famílias de instâncias do ECS suportadas por hosts dedicados são herdadas daquelas suportadas pelos hosts compartilhados. Nos próximos artigos vamos falar sobre Tipos de host dedicados.

Região: A localização física do datacenter onde o servidor físico de um host dedicado está localizado. Em breve, teremos um artigo sobre Regiões e zonas.

Elastic Compute Service (ECS): Um serviço básico de computação em nuvem fornecido pela Alibaba Cloud. Já falamos sobre O que é ECS.

Instância do ECS: Um servidor em nuvem criado em um host compartilhado ou dedicado. Uma instância é equivalente a uma máquina virtual e inclui componentes básicos de computação, como CPU, memória, sistema operacional, rede e disco

Console ECS: O console ECS é a interface da Web para gerenciar recursos ECS e DDH.

Modernização de Datacenter: Azure Stack HCI

29 de dezembro de 2020 Deixe um comentário

Há muito tempo, os datacenters tradicionais são vistos, por muitos profissionais, sendo ambientes ultrapassados e que não se justificam mais, seja pelo alto investimento ou pelo retorno ou mesmo pela adoção de computação em Nuvem.

Seja falando de fabricantes como VMware (Com seu ambiente poderoso de HCI, unindo o melhor do vSphere, do vSAN e do NSX), passando por players de nicho como Nutanix, HP SImplivity, Cisco (Com HyperFlex), DataCore, DellEMC, StratoScale, e com o Azure Stack HCI.

Como o próprio Wikipedia descreve HCI:

“A infraestrutura hiper convergente (HCI) é uma infraestrutura de TI definida por software que virtualiza todos os elementos dos sistemas convencionais “definidos por hardware”. HCI inclui, no mínimo, computação virtualizada (um hipervisor), armazenamento definido por software e rede virtualizada (rede definida por software). HCI normalmente é executado em servidores comerciais off-the-shelf (COTS).

A principal diferença entre infraestrutura convergente (CI) e infraestrutura hiperconvergente é que em HCI, tanto a rede de área de armazenamento quanto as abstrações de armazenamento subjacentes são implementadas virtualmente em software (no ou por meio do hipervisor) em vez de fisicamente, em hardware. [Citação necessário] Como todos os elementos definidos por software são implementados no contexto do hipervisor, o gerenciamento de todos os recursos pode ser federado (compartilhado) em todas as instâncias de uma infraestrutura hiperconvergente.”

Fonte: https://en.wikipedia.org/wiki/Hyper-converged_infrastructure

Muitos profissionais que usam Hyper-V, sabem o poder e o valor da virtualização Microsoft e de como ela está comprometida em dar aos clientes e usuários do Hyper-V o suporte contínuo e a funcionalidade que precisam para permanecer na vanguarda da computação virtual.

O Azure Stack HCI é o mais recente e potente passo em frente para Hyper-V e seus usuários, uma vez que as empresas estão obtendo benefícios incríveis com as mais recentes tecnologias de nuvem e migrando cada vez mais os recursos e poder de computação nessa direção. No entanto, nem tudo pode ir para as nuvens públicas. Ainda há um grande interesse e até mesmo regras de negócios que precisam estar “dentro de casa”.

Pensando nisso, a Microsoft está trazendo o Azure Stack HCI, que oferece a infraestrutura de tecnologia para modernizar seus datacenters, simplificar o gerenciamento de recursos locais e na nuvem, integrar sua vantagem e ramificações remotas em sua infraestrutura central, e dar mais controle sobre o próprio hardware, escalabilidade, e ambiente de nuvem.

O poder da modernização

Quando falamos em modernizar não estamos falando apenas do que é necessário, mas do que inevitável em última instância. Nesse sentido, estamos tratando do que também é benéfico.

O mundo da tecnologia mudou e muda muito ano após ano, e desde o lançamento do Hyper-V as mudanças foram incríveis. O Hyper-V continua sendo um hipervisor de elite, mas foi construído como um hipervisor não como uma solução de serviço completo para um datacenter empresarial de 2020.

Quando o Azure Stack HCI foi apresentado, como um novo sistema operacional host de infraestrutura hiper convergente, ele foi entregue como um serviço do Azure que fornece atualizações de segurança, desempenho e recursos mais recentes e atualizadas.

Pois bem! Durante os próximos dias, vamos nos aprofundar no que mudou desde que o Hyper-V foi introduzido (Estamos falando desde drives SSD superando o HDD, quantidade de núcleos e RAM exigidos pelos hosts atuais, computação em nuvem, borda e cluster).

O trabalho remoto está aumentando significativamente com os acontecimentos mundiais tivemos uma aceleração na adoção desse modelo.

O Hyper-V está totalmente adaptado às mudanças, e da mesma forma, tem um desempenho excelente na função de hipervisor de virtualização. Estamos falando de uma solução completa construída para o mundo atual e é mais adequada para o ecossistema de computação moderno.

Mas, vamos voltar para o tema Modernização?

Modernizar sistemas baseados em Hyper-V anteriores para o Azure Stack HCI vai fornecer uma vantagem competitiva. Mesmo que o Hyper-V continue sendo crucial, ele se torna muito mais poderoso com HCI infraestrutura em cima dela.

Quanto mais rápido possamos modernizar, mais cedo iremos nos beneficiar do Azure Stack HCI, maior densidade de computação, questões de redução de consumo carbono e custos gerais reduzidos, forçando atualizações ou substituições regulares, faz sentido atualizar para o Azure Stack HCI para economizar espaço no local agora e fazer uma atualização imediata e custos de reposição para o futuro previsível.

Os benefícios de modernizar seu datacenter, uma vez que você tenha uma nova infraestrutura estável em lugar (melhoria na funcionalidade de poder de computação e tempo economizado graças ao gerenciamento de sistema simplificado e uma cadeia de ferramentas unificada), seremos capazes de reduzir custos e complexidade ao mesmo tempo em que aumenta sua eficiência, maximiza a virtualização e se beneficia ainda mais de Integrações do Azure e recuperação de desastres nativa.

Por que híbrido e por que HCI?

A computação híbrida combina o melhor dos dois mundos, e permite que conecte seus recursos locais e na nuvem.

Embora claramente este seja uma melhoria sobre como gerenciá-los separadamente, os pontos de dor permanecem inerentes ao híbrido não-HCI computação, já que esses recursos, embora conectados, ainda são discretos. Permitindo que as VMs simultaneamente ao vivo no local enquanto ainda está conectado à nuvem, também pode impor computação, armazenamento, e limitações de rede no lado local do sistema.

Com o Azure Stack HCI podemos atender à maior demanda de nuvem do sistema também pode se tornar insustentável. Essas limitações precisam de produtos, correções ou soluções alternativas adicionais que podem aumentar o custo, a complexidade ou o potencial por erro.

Muitos clientes que adotaram um modelo de sistema híbrido podem sofrer de gerenciamento em escala sem brilho. Muitos clientes adotaram o Microsoft System Center para gerenciar mais do que algumas VMs por vez. Esses clientes que investiram e adotara o System Center para gerenciamento, podem se valer desse investimento pois ele funcionará em conjunto com o Azure Stack HCI e assim, poderá aumentar essa combinação com ferramentas híbridas baseadas em Azure, como Site Recovery e Azure Monitoramento.

Inúmeros e valiosos recursos de dimensionamento, como auditoria granular e gerenciamento, são bons exemplos do que o HCI pode fazer pelo ambiente legado. Do outro lado as ferramentas de monitoramento e gerenciamento do Azure garantem a interface elusiva de “painel único” (por meio da integração com o Azure Arc) para gerenciar tudo em um lugar.

Nos próximos artigos, vamos conhecer mais sobre essa solução que Microsoft nos traz.

Como criar instâncias ECS em um host dedicado

29 de dezembro de 2020 Deixe um comentário

Vamos falar sobre como criar e configurar instâncias do Elastic Compute Service (ECS) em um host dedicado.

Vamos aos detalhes:

  1. Pré-requisitos

Antes de qualquer coisa, para criar instâncias ECS em um host dedicado, as seguintes condições precisam ser atendidas:

  1. Um host dedicado estar criado.
  2. Uma nuvem privada virtual (VPC) IPv4 criada na região onde o host dedicado reside.
  3. Se não criamos o grupo de segurança padrão, devemos criar um grupo de segurança na região de destino e adicionar regras ao grupo de segurança criado.
  4. Se precisar associar um par de chaves SSH a uma instância do Linux ECS, deverá criar um par de chaves SSH na região onde reside o host dedicado.
  5. Se precisarmos configurar os dados do usuário, deve preparar scripts sobre o comportamento de inicialização das instâncias.

Importante: Antes que uma instância ECS possa assumir uma função RAM, devemos criar a função RAM e autorizar a instância ECS a assumir a função.

Apenas instâncias do ECS conectadas a VPC podem ser criadas em um host dedicado, uma vez que as instâncias do ECS em um host dedicado têm recursos diferentes das instâncias do ECS em um host compartilhado.

Procedimento

  1. Faça logon no console do ECS.
  2. No painel de navegação esquerdo, escolha Instâncias e imagens e depois clique em Hosts dedicados.
  3. Na barra de navegação superior, selecione uma região.
  4. Encontre o host dedicado no qual deseja criar instâncias do ECS. Na coluna Ações, clique em Criar instância.
  5. Especifique os parâmetros na etapa Configurações básicas.
  6. Selecione um host dedicado.

Por padrão, o host dedicado que selecionamos anteriormente na página Hosts dedicados é usado, no entanto podemos selecionar um host dedicado diferente.

  • Selecione ou desmarque a opção Associate with DDH. Esta opção especifica se a instância ainda está implementada no host dedicado atual se a instância for interrompida, liberada ou reiniciada.

Se você selecionar a opção Associate with DDH, a instância será implementada no host dedicado atual, caso os recursos do host dedicado forem insuficientes, a instância não será reiniciada.

Importante: Se você desmarcar a opção Associate with DDH, a instância será implantada em outro host dedicado de sua conta do Alibaba Cloud se os recursos do host dedicado atual forem insuficientes. Para evitar isso o host dedicado deve estar disponível para implantação automática da instância.

  • Selecione um método de cobrança.

Nesse caso, devemos selecionar o método de faturamento para as instâncias do ECS com base no método de faturamento do host dedicado, onde podemos optar Assinatura ou Pay-As-You-Go como o método de cobrança de instâncias ECS executadas em um host dedicado de assinatura.

  • Especifique o tipo e a quantidade de instâncias ECS.

A região e a zona da instância do ECS devem ser iguais às do host dedicado. Os tipos de instância disponíveis dependem do tipo e dos recursos de computação disponíveis do host dedicado.

  1. Se o host dedicado suportar apenas tipos de instância predefinidos, clique em Tipo de instância predefinida. Em seguida, selecione o tipo de instância na seção Tipo de Instância.
  2. Se o host dedicado oferecer suporte a tipos de instância personalizados, clique em Tipo de instância personalizada. Em seguida, podemos ajustar para especificar o número de vCPUs e o tamanho da memória. O número mínimo de vCPUs é 1. Se mais de uma vCPUs for necessária, precisamos definir este parâmetro para um número par, por exemplo, 2 ou 4. O tamanho mínimo da memória é 1 GiB. Tipo de instância personalizada
  3. Selecione a imagem.

Importante: Você pode selecionar uma imagem pública, imagem personalizada, imagem compartilhada ou uma imagem adquirida no Alibaba Cloud Marketplace.

Disclaimer: Para associar o par de chaves SSH à instância do ECS, devemos selecionar um sistema operacional Linux na lista suspensa da imagem.

  1. Para configurar os dados do usuário da instância, devemos selecionar uma imagem que ofereça suporte aos dados do usuário.
  2. Configure o armazenamento.
  3. Disco do sistema: necessário. O disco do sistema é usado para instalar o sistema operacional, nesse caso devemos especificar o tipo e a capacidade do disco do sistema.
  4. Tipo de disco: Todos os tipos de discos disponíveis na região de destino estão listados nesta seção.
  5. Capacidade: a capacidade padrão do disco do sistema é 40 GiB. A capacidade máxima é de 500 GiB. Se o tamanho da imagem selecionada for maior que 40 GiB, o tamanho da imagem será o valor padrão. O tamanho mínimo do disco do sistema está relacionado à imagem que você selecionou.

Próximos passos:

  1. Podemos usar o serviço FTP para fazer upload de arquivos locais para as instâncias do ECS.
  2. Depois que as instâncias do ECS são criadas, é recomendado verificar se os sistemas operacionais são compatíveis e protegidos.
  3. Fortalecer a segurança do sistema operacional para Linux.
  4. Aumentar a segurança do sistema operacional para Windows.
  5. Se foram adicionados discos de dados durante a criação da instância, as partições dos discos de dados devem ser formatadas antes que os discos de dados possam ser usados. do Linux ou Formatar um disco de dados para uma instância do Windows ECS.

Links importantes:

https://www.alibabacloud.com/help/doc-detail/68984.htm?spm=a2c63.p38356.879954.4.266d7de5Z70ETM#task-fbz-5mn-tdb

https://www.alibabacloud.com/help/doc-detail/65430.htm?spm=a2c63.p38356.879954.6.266d7de5Z70ETM#task-1512598

https://www.alibabacloud.com/help/doc-detail/25468.htm?spm=a2c63.p38356.879954.7.266d7de5Z70ETM#concept-ocl-bvz-xdb

https://www.alibabacloud.com/help/doc-detail/71427.htm?spm=a2c63.p38356.879954.12.266d7de5Z70ETM#concept-wwk-jkn-tdb

https://ecs.console.aliyun.com/?spm=a2c63.p38356.879954.13.266d7de5Z70ETM

https://www.alibabacloud.com/help/doc-detail/118938.htm?spm=a2c63.p38356.879954.14.266d7de5Z70ETM#concept-265538

https://www.alibabacloud.com/help/doc-detail/68564.htm?spm=a2c63.p38356.879954.15.266d7de5Z70ETM#concept-h3g-zzm-tdb

https://www.alibabacloud.com/help/doc-detail/111486.htm?spm=a2c63.p38356.879954.16.266d7de5Z70ETM#concept-h44-kwj-dhb

Associando uma instância ECS a um host dedicado

29 de dezembro de 2020 Deixe um comentário

Nesse artigo, vamos falar sobre como podemos interromper uma instância do ECS e liberar os recursos de CPU e memória.

Uma vez que precisamos de recurso, podemos usar uma instância ainda seja implantada no host dedicado original ao reiniciá-la, e assim poder associar a instância ao host dedicado.

Nesse tópico, vamos descrever como associar uma instância ECS a um host dedicado passo a passo. Em breve, teremos um vídeo falando sobre isso.

  1. Pré-requisitos:

Precisamos ter criado uma instância ECS em um host dedicado.

Consulte Criar uma instância ECS em um host dedicado.

  • Procedimento:
  1. Faça logon na console do ECS.
  2. No painel de navegação do lado esquerdo, escolha Instâncias e imagens, depois clique em Instâncias.
  3. Na barra de navegação superior, selecione uma região.
  4. Selecione a instância ECS de destino. Na coluna Actions, escolha More, depois clique em Instance Settings e após isso em Modify DDH Deployment.
  5. Na caixa de diálogo Modify DDH Deployment, na lista Associate with DDH, selecione Yes.

Importante: Depois que a instância do ECS é associada ao host dedicado, se a instância for interrompida com seus recursos de computação liberados, a instância reiniciada ainda será implantada no host dedicado. Se os recursos disponíveis do host dedicado forem insuficientes, a instância não será reiniciada.

  • Clique OK.

Como resultado, teremos:

  1. Na coluna Associate with DDH da instância, o valor é alterado para Yes. Você pode ver os resultados executando as seguintes etapas:
  2. No painel de navegação à esquerda, escolha Hosts dedicados.
  3. Selecione o host dedicado em que reside a instância ECS de destino. Na coluna Operações, clique em Detalhes.
  4. Na lista Instâncias, selecione a instância ECS de destino e marque a coluna Associate with DDH.

Habilitar renovação automática: Para evitar o lançamento acidental de um host dedicado de assinatura em caso de esquecer de renovar a assinatura, podemos habilitar a renovação automática para o host dedicado. Depois de habilitar a renovação automática, o sistema renova automaticamente a assinatura do host dedicado.

Agora, vamos descrever como habilitar a renovação automática. A renovação automática pode ser ativada durante e após a criação de um host dedicado.

Pré-requisitos

O status de um host dedicado de assinatura não pode estar Expirado.

Depois que a renovação automática é habilitada, o Alibaba Cloud a cobrança será pela renovação de seus cartões de crédito ou contas do PayPal na data de expiração (T). Se a dedução da taxa falhar, a taxa é deduzida novamente 7 dias (D + 6) e 15 dias (D + 14) após o vencimento até que a renovação seja bem-sucedida. Se a renovação falhar todas as três vezes, o host dedicado será interrompido.

Podemos habilitar o recurso de renovação automática durante e depois de criar um host dedicado.

Ative a renovação automática ao criar um host dedicado: Se o recurso de renovação automática for habilitado quando um host dedicado é criado, o ciclo de faturamento é baseado na duração da assinatura que é selecionada quando você compra o host dedicado:

  • Para assinaturas anuais: Ciclo de faturamento é de um ano.
  • Para assinaturas mensais, o ciclo de faturamento é de um mês.
  • Para assinaturas semanais, o ciclo de faturamento é de uma semana.

Ative a renovação automática após criar um host dedicado:

  1. Faça logon no console do ECS.
  2. No painel de navegação esquerdo, escolha Instâncias e imagens> Hosts dedicados.
  3. Na barra de navegação superior, selecione uma região.
  4. Selecione o host dedicado de destino. Escolha Ações> Alterar configurações de renovação.
  5. Na caixa de diálogo Alterar Configurações de Renovação, execute as seguintes etapas.
  6. Ative o botão Ativar renovação automática.
  7. Na lista Duração, selecione a duração da renovação automática.
  8. Clique em Confirmar.