Essa solução demonstra como alcançar o dimensionamento entre clusters de cargas de trabalho implantadas em uma infraestrutura híbrida. Essa solução é obtida aplicando os recursos de escalabilidade e gerenciamento de serviços habilitados para Azure Arc em clusters do Azure Stack HCI.
Arquitetura
A arquitetura mostra a implantação de soluções híbridas usando serviços habilitados para Azure Arc no Azure Stack HCI, no Azure Pipelines e na integração de um balanceador de carga global e um Aplicativo de Funções do Azure.
Baixe um Arquivo Visio dessa arquitetura.
Workflow
A arquitetura consiste nas seguintes etapas:
Dois clusters do Azure Stack HCI são configurados em dois locais diferentes: o Azure Stack HCI (HCI1) serve como infraestrutura local primária e o Azure Stack HCI (HCI2) como infraestrutura local secundária para a execução de cargas de trabalho.
Os clusters do Azure Stack HCI se conectam ao Azure por meio do SD-WAN e são gerenciados por meio do Azure Arc e do Windows Admin Center. Como resultado, você pode estender os recursos do Azure para a infraestrutura local e usar ferramentas e serviços de gerenciamento do Azure para gerenciar e monitorar a infraestrutura e a carga de trabalho locais.
O Serviço de Kubernetes do Azure (AKS), implantado no Azure Stack HCI, é composto pelo cluster de gerenciamento (host AKS) e clusters de carga de trabalho (também conhecidos como clusters de destino) em que os aplicativos em contêineres são implantados. Confira a arquitetura de linha de base do Serviço de Kubernetes do Azure (AKS) para AKS no Azure Stack HCI.
O host do Serviço de Kubernetes do Azure no Azure Stack HCI e cluster de carga de trabalho são implantados usando módulos do PowerShell do AksHci. Confira Usar o PowerShell para configurar o Kubernetes em clustersdo Azure Stack HCI e do Windows Server.
A virtualização dos recursos de rede é implementada aplicando recursos de SDN do cluster do Azure Stack HCI. Ela implanta os recursos necessários de infraestrutura de rede SDN, como VMs do Mux do Balanceador de Carga de Software, VMs de Gateway de RAS e Controladores de Rede para maior disponibilidade de rede. Confira Rede definida por software (SDN) no Azure Stack HCI e no Windows Server.
As VMs de carga de trabalho e infraestrutura do AKS são implantadas em uma Rede Virtual SDN com balanceamento de carga híbrido obtido por meio do Software Load Balancer (SLB) da SDN. Confira Implantar a rede definida por software (SDN) da Microsoft com o AKS no Azure Stack HCI.
O Azure Pipelines implanta os aplicativos de front-end com as mesmas versões dos aplicativos conteinerizados implantados em ambientes locais do Azure Stack HCI.
Os bancos de dados são hospedados em Instâncias Gerenciadas de SQL habilitadas para Arc implantadas no AKS híbrido.
Um desenvolvedor empacota seus aplicativos como um contêiner a ser implantado em clusters híbridos do AKS usando manifestos do Kubernetes e módulos do PowerShell do AksHci e automatiza tarefas de implantação por meio do Azure Pipelines.
Uma solicitação de cliente para o aplicativo é direcionada por um serviço de balanceador de carga global, como o Azure Front Door ou o Gerenciador de Tráfego do Azure, que roteia a solicitação para o ponto de extremidade de serviço apropriado usando um método de roteamento de tráfego ponderado. Com base no percentual ponderado atribuído, o tráfego é distribuído aos serviços implantados nos dois clusters híbridos do AKS no Stack HCI.
O Gerenciador de Tráfego e o Azure Front Door são opções viáveis para lidar com recursos globais de balanceamento de carga devido à presença de clusters em várias regiões. A seleção entre o Azure Front Door e o Gerenciador de Tráfego depende de vários fatores e a decisão de recomendar um sobre o outro requer uma consideração cuidadosa. Aqui estão alguns motivos para considerar diferentes serviços de balanceamento de carga:
- Se seus aplicativos voltados para a Internet usarem HTTPS, o Azure Front Door será a opção preferível. Geralmente, o Gerenciador de Tráfego não é a principal opção nesses casos. Embora possa haver exceções, cenários específicos estão além do escopo dessa discussão.
- Se sua meta principal for um balanceamento de carga global eficiente, o Gerenciador de Tráfego poderá ser suficiente. Se você também precisar de otimização de entrega de conteúdo, segurança de camada de aplicativo e recursos de roteamento mais avançados, o Azure Front Door poderá ser um ajuste melhor.
- O Gerenciador de Tráfego é mais simples de configurar e concentra-se principalmente no balanceamento de carga. O Azure Front Door oferece mais recursos, mas pode ter uma curva de aprendizado mais íngreme.
- Considere o tipo de aplicativo. Se ele for mais centrado na Web e você precisar de otimizações como cache e encerramento de SSL, o Azure Front Door poderá ser benéfico.
- Em relação ao roteamento baseado em DNS, a complexidade diminui ao lidar com o balanceamento de carga no nível do aplicativo. No entanto, é crucial observar que depender apenas do roteamento baseado em DNS pode levar a um maior tempo de inatividade durante uma falha, o que pode afetar negativamente os Contratos de Nível de Serviço (SLAs) de seus aplicativos. A decisão entre o Azure Front Door e o Gerenciador de Tráfego deve considerar o SLA da solução DNS e se seu aplicativo pode acomodar os diferentes tempos de failover entre as duas opções.
Os aplicativos de carga de trabalho implantados são monitorados para carga usando serviços habilitados para Azure Arc, o Azure Monitor e o Workspace do Log Analytics.
Em condições normais de carga, a solicitação do cliente é roteada para a instância do aplicativo hospedado localmente no ambiente do Azure Stack HCI-1 (ambiente de cluster primário).
As cargas de trabalho de cluster do AKS habilitadas para Arc são projetadas para dimensionar horizontalmente para várias instâncias usando o dimensionador automático interno, que aumenta ou reduz automaticamente o número de nós no cluster do AKS implantado com base na demanda.
Os insights de contêiner estão habilitados para capturar o diagnóstico e monitorar o desempenho da carga de trabalho no cluster do Kubernetes hospedado nos HCIs do Azure Stack.
Quando há um aumento no tráfego e o cluster de carga de trabalho no Azure Stack HCI-1 atinge sua contagem máxima de nós sem mais opções de dimensionamento de pod, ele gera um alerta para disparar um aplicativo de funções do Azure.
Uma regra de alerta é configurada para monitorar o resultado de uma consulta Kusto personalizada, que verifica a contagem máxima de nós e a porcentagem de preparação do pod das tabelas KubeNodeInventory e KubePodInventory do Azure Monitor. Confira Criar alertas de log com base em insights de contêiner.
O monitoramento do Kubernetes também pode ser executado usando regras de alerta pré-configuradas dos insights do Contêiner do Kubernetes. Você também pode aplicar as regras de métrica kubePodNotReady ou KubeHpaMaxedOut de insights de contêiner para configurar condições de regra de alerta. Confira Regras de alerta de métrica em insights de contêiner (versão prévia) e invoque o Aplicativo de Funções do Azure por meio do Grupo de Ações do Alerta.
O Aplicativo de Funções do Azure gerencia dinamicamente regras de roteamento de tráfego ponderadas com base na condição do cluster primário e redireciona o tráfego para o cluster do Azure Stack HCI-2.
- Você pode usar Funções do Azure para calcular o percentual de tráfego que deve ser redirecionado com base nos limites de limite predefinidos de preparação do cluster e condições de tráfego. Isso pode ajudá-lo a se adaptar às mudanças rapidamente, automatizar tarefas, dimensionar recursos com eficiência e economizar dinheiro.
- As Funções do Azure ajudam a gerenciar regras de roteamento de tráfego dinamicamente. Essa funcionalidade garante alta disponibilidade, escalabilidade e desempenho e fornece uma experiência de usuário perfeita mesmo durante os cenários de pico de tráfego e failover. Por exemplo, a Distribuição de Tráfego inicial começa com a direcionamento de 100% do tráfego para o cluster primário quando ele está tendo um bom desempenho e é capaz de lidar com a carga. Quando o cluster primário estiver quase cheio ou apresentar degradação de desempenho, você poderá ajustar as regras de roteamento de tráfego nas Funções do Azure. Isso redireciona parte do tráfego somente leitura para o cluster secundário.
Instâncias de aplicativo em execução em ambos os ambientes de cluster se conectam aos serviços de dados, como Instâncias Gerenciadas de SQL habilitadas para Arc, localmente dentro de seus respectivos clusters.
A sincronização de dados entre os clusters para Instâncias Gerenciadas de SQL do Arc é regida pelo Grupo de Failover do Azure, que, por sua vez, usa os Grupos de Disponibilidade Distribuída. A sincronização entre clusters pode ser síncrona ou assíncrona. Confira a Instância Gerenciada de SQL habilitada para Azure Arc.
No geral, esse fluxo de trabalho envolve a criação e implantação de aplicativos, balanceamento de carga, gerenciamento de tráfego, dimensionamento automático e sincronização de dados em vários ambientes de cluster. Essa configuração permite dimensionar a infraestrutura horizontalmente entre clusters em dois data centers ou locais diferentes, fornecendo segurança, redundância, flexibilidade e utilização eficiente de recursos.
Componentes
O Azure Front Door é um balanceador de carga de camada 7. Nessa arquitetura, ele roteia solicitações HTTP para os aplicativos Web implantados no cluster do Stack HCI. Você também pode usar um firewall do aplicativo Web (WAF) com o Azure Front Door que protege o aplicativo contra explorações e vulnerabilidades comuns e uma solução da Rede de Distribuição de Conteúdo (CDN) nesse design para reduzir a latência e melhorar o tempo de carregamento de conteúdo armazenando em cache o conteúdo nos locais de borda.
O Gerenciador de Tráfego é um balanceador de carga de tráfego baseado em DNS e uma opção viável de balanceamento de carga. Use-o para controlar a distribuição do tráfego de aplicativos para pontos de extremidade de serviço em data centers diferentes. Veja como funciona a configuração do Gerenciador de Tráfego:
- Configure o Gerenciador de Tráfego, uma solução global de balanceamento de carga no Azure, para distribuir o tráfego de entrada em seus clusters do Azure Stack HCI. O Gerenciador de Tráfego pode ser configurado para usar diferentes métodos de balanceamento de carga, como desempenho, failover ou round robin ponderado, dependendo dos requisitos.
- Crie pontos de extremidade do Gerenciador de Tráfego que correspondam aos pontos de extremidade das cargas de trabalho implantadas em clusters do Azure Stack HCI. Isso permite que o Gerenciador de Tráfego direcione o tráfego para o ponto de extremidade apropriado. Nesse cenário, o tráfego direto com base no método de balanceamento de carga de roteamento ponderado.
- Com base nas políticas de dimensionamento calculadas por meio de uma função do Azure, quando há a necessidade de capacidade extra ou alta disponibilidade, o Gerenciador de Tráfego pode rotear dinamicamente o tráfego para outras instâncias com base nas regras de roteamento e seus percentuais ponderados.
O Application Insights coleta dados de telemetria de vários componentes implantados nesta solução híbrida. Ele fornece insights e análises que podem ser usados para identificar problemas, otimizar o desempenho e melhorar a experiência do usuário.
O Azure Functions atua como um orquestrador para distribuição de tráfego. Ele monitora as condições de preparação de cada cluster, avaliando fatores como utilização de recursos, latência e integridade. Com base nessa avaliação, o Aplicativo de Funções decide para onde direcionar o tráfego de entrada.
O Azure Stack HCI é uma solução de cluster de HCI (infraestrutura hiperconvergente) que hospeda cargas de trabalho virtualizadas dos sistemas operacionais do Windows e Linux e seu armazenamento em um ambiente híbrido que combina infraestrutura local com serviços do Azure.
- A solução usa o Serviço de Kubernetes do Azure no Azure Stack HCI (AKS-HCI) para hospedar o aplicativo Web ou APIs, Servidores do Azure habilitados para Arc e Serviços de Dados Habilitados para Arc em ambos os ambientes.
O Azure DevOps Services serve como base para essa estratégia de implantação de solução híbrida, fornecendo a automação e a orquestração necessárias para simplificar todo o ciclo de vida de entrega de software. Ele capacita as equipes de desenvolvimento a se concentrarem em fornecer código de alta qualidade enquanto o pipeline cuida da criação, teste e implantação de aplicativos.
Para implantar um cluster do AKS no Azure Stack HCI, você pode configurar um servidor de build no Azure Pipelines. O servidor de build é responsável por executar o processo de implantação.
a. Crie uma máquina virtual (VM) no Azure ou em uma VM a partir do ambiente do Stack HCI. Ou use uma VM local existente como servidor de build se ela tiver conectividade de rede com as infraestruturas híbridas.
b. Instale as ferramentas necessárias no servidor de build, como Git, CLI do Azure e módulos do Azure PowerShell.
c. Configure a autenticação no Azure configurando entidades de serviço ou usando identidades gerenciadas.
O Azure Pipelines é um serviço que fornece CI/CD e gerencia os agentes e definições de build e lançamento hospedados. O pipeline de desenvolvimento pode usar vários repositórios de código, incluindo GitHub, Bitbucket, Dropbox, OneDrive e Azure Repos.
O Azure Monitor coleta dados de telemetria e monitora o desempenho de clusters e cargas de trabalho. Ele também permite que você configure alertas para disparar uma Função do Azure ou notificar um administrador se algum cluster se tornar não íntegro ou se os limites predefinidos forem excedidos. Você pode usar a Automação do Azure ou os Aplicativos Lógicos do Azure para automatizar ações de dimensionamento com base nos dados de monitoramento.
O Azure Policy atua como um executor de governança e conformidade, garantindo que os clusters do Stack HCI e os recursos de SDN associados operem dentro das diretrizes e padrões definidos. Aqui estão alguns exemplos para aprimorar a segurança do ambiente por meio do Azure Policy:
- Impor o complemento de insights de contêiner
- Instalação de extensões essenciais em clusters do Stack HCI
- Impor a marcação de recursos
- Controle de acesso baseado em política
- Políticas relacionadas à rede e ao monitoramento
O Registro de Contêiner do Azure é um serviço de registro do Docker privado gerenciado no Azure. Use o Registro de Contêiner para armazenar imagens privadas do Docker, que são implantadas no cluster.
O Azure Arc estende os serviços do Azure para ambientes locais, permitindo que as organizações se beneficiem dos recursos de nuvem, mantendo dados confidenciais dentro de sua própria infraestrutura.
Os insights de contêiner são uma solução de monitoramento e observabilidade fornecida pelo Azure Monitor que permite obter insights sobre o desempenho e a integridade de contêineres em execução em clusters do AKS. Com o Azure Arc habilitado para AKS, você pode estender os recursos de insights de contêiner para monitorar e gerenciar seus clusters do AKS que estão em execução fora do Azure, como para ambientes locais ou multinuvem.
As Instâncias Gerenciadas de SQL habilitadas para Arc é um serviço de dados SQL do Azure que pode ser criado na infraestrutura do Stack HCI e gerenciado usando o Azure Arc.
O Azure Key Vault permite que você armazene e gerencie com segurança chaves criptográficas, segredos e certificados. Embora o Azure Key Vault seja principalmente um serviço de nuvem, ele também pode ser usado com implantações do Azure Stack HCI para armazenar e gerenciar informações confidenciais com segurança local.
Infraestrutura do SDN. Em uma implantação híbrida do AKS no Azure Stack HCI, o balanceamento de carga é obtido por meio do SDN do software Load Balancer (SLB). O SLB gerencia a infraestrutura e os aplicativos do AKS-HCI dentro da Rede Virtual SDN (rede definida pelo software), incluindo os recursos necessários de infraestrutura de rede SDN, como VMs do balanceador de carga do Mux, VMs de Gateway e Controladores de Rede.
Aqui está um detalhamento dos componentes envolvidos:
- Balanceador de Carga de Software (SLB): o SLB é um componente fundamental da infraestrutura do AKS-HCI que fornece recursos de balanceamento de carga para distribuir o tráfego de rede para os aplicativos em execução no cluster. Ele opera na camada de transporte (Camada 4) e direciona o tráfego com base nas regras configuradas.
- VMs do balanceador de carga Mux: as VMs do balanceador de carga Mux são máquinas virtuais que lidam com o tráfego de rede de entrada de fontes externas e a distribuem para os pods ou serviços de back-end apropriados dentro do cluster do AKS-HCI. Elas trabalham com o SLB para executar o balanceamento de carga.
- VMs de gateway: as VMs de gateway fornecem conectividade entre o cluster do AKS-HCI e redes externas. Elas atuam como uma ponte entre a Rede Virtual SDN interna e redes externas, permitindo que o tráfego de entrada e saída flua com segurança.
- Controladores de rede: os controladores de rede são responsáveis por gerenciar a infraestrutura do SDN dentro do cluster do AKS-HCI. Eles lidam com tarefas como imposição de política de rede, configuração de rede e configuração do balanceador de carga.
Usando SLB, VMs do balanceador de carga Mux, VMs de gateway e controladores de rede, o AKS-HCI obtém o balanceamento de carga para implantações híbridas. Ele garante que o tráfego de rede de entrada seja distribuído com eficiência entre os aplicativos em execução no cluster, fornecendo alta disponibilidade e escalabilidade.
Observação
Esses componentes são gerenciados e configurados pelo AKS-HCI, permitindo que você se concentre na implantação e gerenciamento de seus aplicativos ao usar os recursos internos de balanceamento de carga da plataforma.
Alternativas
Para aplicativos Web e serviços baseados em eventos, você pode executar o Serviço de Aplicativo, Funções e Aplicativos Lógicos em um cluster do Kubernetes habilitado para Azure Arc hospedado no Azure Stack HCI. Para o banco de dados, você pode usar outra opção de armazenamento, como o servidor PostgreSQL habilitado para Azure Arc.
Para aplicativos Web, você pode usar o Azure Front Door. O Azure Front Door funciona na Camada 7, a camada HTTP/HTTPS. Ele usa o protocolo anycast com TCP dividido e a rede global da Microsoft para melhorar a conectividade global. Seu método de roteamento pode garantir que o Azure Front Door encaminhe suas solicitações de cliente para o back-end de aplicativo mais rápido e disponível.
Você pode usar o Azure ExpressRoute para conectar sua rede local diretamente aos recursos do Azure usando uma conexão de rede privada dedicada.
Se o repositório estiver no GitHub, você poderá usar o GitHub Actions em vez do Azure Pipelines.
Detalhes do cenário
O objetivo principal é facilitar o dimensionamento entre clusters distribuindo efetivamente cargas de trabalho entre clusters situados em dois data centers ou locais diferentes. Essa abordagem impede a sobrecarga de qualquer cluster individual e otimiza a utilização de recursos em todos os clusters. O Aplicativo de Funções do Azure desempenha um papel fundamental na distribuição inteligente do tráfego com base nas condições de preparação do cluster, aumentando assim a eficiência, a escalabilidade, a disponibilidade e o desempenho.
Esse cenário é aplicável para organizações que lidam com um conjunto estrito de restrições, regulamentos de soberania de dados ou necessidades cruciais de resiliência e continuidade de negócios ou para lidar com cargas de trabalho críticas em ambientes altamente restritos e regulamentados, como bancos, finanças, defesa e governo. Devido às políticas regulatórias e de conformidade das organizações, aplicativos e bancos de dados são executados localmente para impedir a exposição de dados confidenciais ou sensíveis na nuvem pública. Essa solução é útil quando:
Os aplicativos locais experimentam picos de uso durante a alta temporada e o dimensionamento automático dentro do cluster, mas o cluster primário atinge 100% de capacidade e deseja desviar o tráfego de estouro para outro cluster de data center sem interromper nenhuma execução de serviço.
Você deseja resolver o redirecionamento do tráfego de aplicativo/API automaticamente para o ambiente local mais próximo disponível.
Você deseja simplificar a governança e o gerenciamento da instalação local e acessar serviços de nuvem relevantes que são filtrados por meio de um firewall ou servidor proxy de maneira consistente e segura por meio dos serviços habilitados para Azure Arc implantados no Azure Stack HCI.
Possíveis casos de uso
- Você deseja implementar cargas de trabalho altamente disponíveis, escalonáveis, protegidas e restritas em um ambiente de cluster do Azure Stack HCI local.
- Você deseja realizar dimensionamento dinâmico de aplicativos em execução entre os datacenters sempre que os aplicativos locais experimentarem picos em seus usos.
- Você deseja aplicar a automação baseada em nuvem com gerenciamento, governança e monitoramento centralizados.
- Você tem componentes locais e deseja usar outra configuração local para dimensioná-los.
- Você deseja que a escalabilidade dinâmica entre clusters execute seus aplicativos localmente até o momento em que você pode estender o dimensionamento de suas cargas de trabalho para instâncias de nuvem.
Considerações
Estas considerações implementam os pilares do Azure Well-Architected Framework, que é um conjunto de princípios de orientação que podem ser usados para aprimorar a qualidade de uma carga de trabalho. Para obter mais informações, confira Microsoft Azure Well-Architected Framework.
Confiabilidade
A confiabilidade garante que seu aplicativo possa cumprir os compromissos que você assume com seus clientes. Para obter mais informações, confira Visão geral do pilar de confiabilidade.
Uma empresa pode adotar uma abordagem híbrida para manter seus sistemas mantendo aplicativos e recursos locais por motivos regulatórios e de desempenho. Se desejar aplicar recursos de nuvem do Azure, ela poderá implantar a mesma versão de aplicativos hospedados no Cluster HCI do Azure em várias regiões. Isso atende à conformidade dos serviços altamente disponíveis e escalonáveis.
Segurança
A segurança fornece garantias contra ataques deliberados e o abuso de seus dados e sistemas valiosos. Para saber mais, confira Visão geral do pilar de segurança.
Ao implantar o AKS-HCI, é essencial considerar as práticas de segurança para ajudar a proteger seus aplicativos e infraestrutura. Aqui estão algumas das principais considerações de segurança para o AKS-HCI:
Acesso seguro ao cluster
- Limite o acesso ao cluster AKS-HCI seguindo o princípio do privilégio mínimo. Conceda apenas as permissões necessárias a usuários, grupos ou contas de serviço.
- Use mecanismos de autenticação fortes, como a integração com o Microsoft Entra, o Microsoft Entra Pod Identity ou o controle de acesso baseado em função do Kubernetes (Kubernetes RBAC) para controlar o acesso ao cluster e seus recursos.
- Considere implementar autenticação multifator (MFA) para acesso ao cluster para adicionar uma camada extra de segurança.
Segurança de rede
- Implemente a segmentação de rede e o isolamento no cluster do AKS-HCI usando políticas de rede do Kubernetes ou grupos de segurança de rede do Azure.
- Controlar o tráfego de entrada e saída com firewalls de nível de rede, como o Firewall do Azure, e restringir o acesso com base na lista de permissões de IP ou emparelhamento de rede virtual.
- Criptografe o tráfego de rede entre serviços usando autenticação TLS (Transport Layer Security) ou a autenticação TLS mútua (mTLS).
Segurança de imagem de contêiner
- Use imagens de contêiner seguras de fontes confiáveis e atualize-as regularmente com os patches de segurança e correções de vulnerabilidade mais recentes.
- Implemente as ferramentas de verificação de imagem e avaliação de vulnerabilidades para identificar e corrigir quaisquer problemas de segurança em imagens de contêiner.
- Use mecanismos de assinatura e verificação de imagem de contêiner para garantir a integridade e a autenticidade das imagens.
Gerenciamento de segredos
- Evite codificar informações confidenciais (como senhas, chaves de API ou cadeias de conexão) no código do aplicativo ou nos arquivos de configuração.
- Use o Azure Key Vault ou uma solução de gerenciamento de segredos seguros para armazenar e recuperar informações confidenciais com segurança.
- Use os segredos do Kubernetes ou a integração do Azure Key Vault para injetar segredos com segurança em seus contêineres de aplicativo.
Monitoramento e registro em log
- Implemente o registro em log centralizado e o monitoramento para clusters do AKS-HCI usando o Azure Monitor ou soluções de terceiros.
- Configure logs de auditoria, logs de contêiner e logs do sistema para capturar eventos críticos de segurança.
- Configure mecanismos de alerta e notificação para detectar e responder proativamente a incidentes de segurança ou anomalias.
Atualizações frequentes e aplicação de patch
- Mantenha os nós de cluster do AKS-HCI e a infraestrutura subjacente atualizados com os patches e atualizações de segurança mais recentes.
- Estabeleça um processo de gerenciamento de patch para garantir a aplicação oportuna de correções de segurança.
Considerações sobre conformidade e regulamentação
- Entenda e esteja em conformidade com regulamentos de conformidade e segurança específicos do setor relevantes (como HIPAA ou PCI DSS) com base nos requisitos da sua organização.
- Implemente controles e práticas de segurança para atender aos padrões de conformidade aplicáveis ao seu setor.
Otimização de custo
A otimização de custos é a análise de maneiras de reduzir as despesas desnecessárias e melhorar a eficiência operacional. Para obter mais informações, confira Visão geral do pilar de otimização de custo.
Algumas considerações de otimização de custo para implantar serviços habilitados para Arc no Azure Stack HCI:
- Dimensione corretamente os nós de cluster do AKS-HCI com base nos requisitos reais da carga de trabalho para evitar o excesso de provisionamento ou subutilização.
- O dimensionamento automático do AKS-HCI ajuda a otimizar a alocação de recursos e reduz os custos durante períodos de baixa demanda. Configure o dimensionamento automático de pod horizontal (HPA) com base na demanda e nos padrões de carga de trabalho para dimensionar automaticamente o número de pods em seu cluster do AKS-HCI.
- Otimização de armazenamento:
- Escolha as opções de armazenamento apropriadas com base nos requisitos de carga de trabalho e nas necessidades de desempenho.
- Considere usar o Armazenamento em Disco do Azure para volumes persistentes ou os Arquivos do Azure para armazenamento de arquivos compartilhados.
- Otimize as configurações de armazenamento, como ajustar o tamanho e o tipo de discos com base nas demandas de carga de trabalho.
- Marcação e gerenciamento de grupo de recursos:
- Implemente a marcação de recursos consistente para rastrear e categorizar recursos.
- Use grupos de recursos para organizar logicamente os recursos, facilitando o gerenciamento e o controle de custos.
- Monitoramento e otimização de custos contínuos:
- Examine regularmente os relatórios de custos e painéis fornecidos pelo Gerenciamento de Custos da Microsoft para identificar oportunidades de economia de custos e otimizar os gastos.
- Use ferramentas como o Assistente do Azure para receber recomendações para otimizar a utilização de recursos, melhorar a segurança e reduzir custos.
- Reduza os esforços de implantação e manutenção com o Azure DevOps Services.
Excelência operacional
A excelência operacional abrange os processos de operações que implantam um aplicativo e o mantêm em execução na produção. Para obter mais informações, confira Visão geral do pilar de excelência operacional.
Eficiência de desempenho
A eficiência do desempenho é a capacidade de dimensionar sua carga de trabalho para atender às demandas colocadas por usuários de maneira eficiente. Para saber mais, confira Visão geral do pilar de eficiência de desempenho.
O principal benefício do dimensionamento entre clusters é a capacidade de fornecer dimensionamento sob demanda com ambientes locais, juntamente com controle total sobre a configuração dentro da rede protegida da sua organização.
Colaboradores
Esse artigo é mantido pela Microsoft. Ele foi originalmente escrito pelos colaboradores a seguir.
Principais autores:
Mayuri Bhavsar | Arquiteto Sênior de Soluções de Nuvem
Vidya Narasimhan | Arquiteto Principal de Soluções de Nuvem
Outros colaboradores:
Himanshu Amodwala | Arquiteto Sênior de Soluções de Nuvem
Nakul Joshi | Gerente Principal de Engenharia de Software
Vineeth Marar | Arquiteto Sênior de Soluções de Nuvem
Para ver perfis não públicos do LinkedIn, entre no LinkedIn.
Próximas etapas
- Padrão do Kubernetes de alta disponibilidade usando o Azure e o Azure Stack Hub
- Documentação do Serviço de Kubernetes do Azure (AKS)