Considerações de planejamento de integração de datacenter para sistemas integrados do Azure Stack Hub
Se você estiver interessado em um sistema integrado do Azure Stack Hub, deve entender as principais considerações de planejamento em torno da implantação e como o sistema se encaixa em seu datacenter. Este artigo fornece uma visão geral de alto nível dessas considerações para ajudá-lo a tomar decisões importantes de infraestrutura para seus sistemas integrados do Azure Stack Hub. Uma compreensão dessas considerações ajuda ao trabalhar com seu fornecedor de hardware OEM enquanto eles implantam o Azure Stack Hub em seu datacenter.
Observação
Os sistemas integrados do Azure Stack Hub só podem ser adquiridos de fornecedores de hardware autorizados.
Para implantar o Azure Stack Hub, você precisa fornecer informações de planejamento ao seu provedor de soluções antes do início da implantação para ajudar o processo a ser rápido e suave. As informações necessárias abrangem informações de rede, segurança e identidade, com muitas decisões importantes que podem exigir conhecimento de muitas áreas e tomadores de decisão diferentes. Você precisará de pessoas de várias equipes em sua organização para garantir que você tenha todas as informações necessárias prontas antes da implantação. Pode ajudar a falar com seu fornecedor de hardware enquanto coleta essas informações, porque eles podem ter conselhos úteis.
Ao pesquisar e coletar as informações necessárias, talvez seja necessário fazer algumas alterações de configuração pré-implantação em seu ambiente de rede. Essas alterações podem incluir a reserva de espaços de endereço IP para a solução Azure Stack Hub, bem como a configuração de seus roteadores, switches e firewalls para se preparar para a conectividade com os novos switches de solução do Azure Stack Hub. Certifique-se de ter o especialista da área temática alinhado para ajudá-lo com seu planejamento.
Considerações sobre planejamento de capacidade
Ao avaliar uma solução do Azure Stack Hub para aquisição, você faz escolhas de configuração de hardware que têm um impacto direto na capacidade geral da solução Azure Stack Hub. Isso inclui as opções clássicas de CPU, densidade de memória, configuração de armazenamento e escala geral da solução (por exemplo, número de servidores). Ao contrário de uma solução de virtualização tradicional, a aritmética simples desses componentes para determinar a capacidade utilizável não se aplica. O primeiro motivo é que o Azure Stack Hub foi arquitetado para hospedar a infraestrutura ou os componentes de gerenciamento dentro da própria solução. A segunda razão é que parte da capacidade da solução é reservada para apoiar a resiliência, atualizando o software da solução de forma a minimizar a interrupção das cargas de trabalho do locatário.
A planilha do planejador de capacidade do Azure Stack Hub ajuda você a tomar decisões informadas para planejar a capacidade de duas maneiras. A primeira é selecionando uma oferta de hardware e tentando encaixar uma combinação de recursos. A segunda é definindo a carga de trabalho que o Azure Stack Hub deve executar para exibir as SKUs de hardware disponíveis que podem dar suporte a ela. Por fim, a planilha pretende ser um guia para ajudar na tomada de decisões relacionadas ao planejamento e à configuração do Azure Stack Hub.
A planilha não se destina a servir como um substituto para sua própria investigação e análise. A Microsoft não faz representações ou garantias, expressas ou implícitas, em relação às informações fornecidas na planilha.
Considerações de gerenciamento
O Azure Stack Hub é um sistema selado, onde a infraestrutura é bloqueada tanto do ponto de vista das permissões quanto da rede. As listas de controle de acesso à rede (ACLs) são aplicadas para bloquear todo o tráfego de entrada não autorizado e todas as comunicações desnecessárias entre os componentes da infraestrutura. Este sistema dificulta o acesso de utilizadores não autorizados ao sistema.
Para gerenciamento e operações diárias, não há acesso irrestrito de administrador à infraestrutura. Os operadores do Azure Stack Hub devem gerenciar o sistema por meio do portal do administrador ou do Azure Resource Manager (via PowerShell ou a API REST). Não há acesso ao sistema por outras ferramentas de gerenciamento, como o Hyper-V Manager ou o Failover Cluster Manager. Para ajudar a proteger o sistema, software de terceiros (por exemplo, agentes) não pode ser instalado dentro dos componentes da infraestrutura do Azure Stack Hub. A interoperabilidade com software de gerenciamento e segurança externo ocorre por meio do PowerShell ou da API REST.
Entre em contato com o Suporte da Microsoft quando precisar de um nível mais alto de acesso para solucionar problemas que não são resolvidos por meio de etapas de mediação de alerta. Através do suporte, há um método para fornecer acesso administrativo total temporário ao sistema para operações mais avançadas.
Considerações sobre identidade
Escolha o provedor de identidade
Você precisará considerar qual provedor de identidade deseja usar para a implantação do Azure Stack Hub, Microsoft Entra ID ou AD FS. Não é possível alternar provedores de identidade após a implantação sem a reimplantação completa do sistema. Se não for proprietário da conta Microsoft Entra e estiver a utilizar uma conta fornecida pelo seu Fornecedor de Soluções na Nuvem, e se decidir mudar de fornecedor e utilizar uma conta Microsoft Entra diferente, terá de contactar o seu fornecedor de soluções para reimplementar a solução a expensas suas.
Sua escolha de provedor de identidade não tem influência sobre as máquinas virtuais (VMs) do locatário, o sistema de identidade, as contas que eles usam ou se eles podem ingressar em um domínio do Ative Directory, e assim por diante. Estas coisas são separadas.
Você pode implantar vários sistemas do Azure Stack Hub com o mesmo tenant do Microsoft Entra ou o Active Directory.
Integração do AD FS e do Graph
Se você optar por implantar o Azure Stack Hub usando o AD FS como o provedor de identidade, deverá integrar a instância do AD FS no Azure Stack Hub com uma instância existente do AD FS por meio de uma confiança de federação. Essa integração permite que identidades em uma floresta existente do Ative Directory sejam autenticadas com recursos no Azure Stack Hub.
Você também pode integrar o serviço Graph no Azure Stack Hub com o Ative Directory existente. Essa integração permite gerenciar Role-Based Controle de Acesso (RBAC) no Azure Stack Hub. Quando o acesso a um recurso é delegado, o componente Gráfico procura a conta de usuário na floresta existente do Ative Directory usando o protocolo LDAP.
O diagrama a seguir mostra o fluxo de tráfego integrado do AD FS e do Graph.
Modelo de licenciamento
Você deve decidir qual modelo de licenciamento deseja usar. As opções disponíveis dependem se você implantar o Azure Stack Hub conectado à Internet:
- Para uma implantação conectada , pode-se escolher entre licenciamento pago conforme uso ou baseado em capacidade. O pagamento conforme o uso requer uma conexão com o Azure para relatar o uso, que é cobrado por meio do comércio do Azure.
- Somente o licenciamento baseado em capacidade é suportado se implantar desconectado da Internet.
Para obter mais informações sobre os modelos de licenciamento, consulte empacotamento e preços do Microsoft Azure Stack Hub.
Decisões de nomeação
Você precisará pensar em como deseja planejar seu namespace do Azure Stack Hub, especialmente o nome da região e o nome de domínio externo. O FQDN (nome de domínio totalmente qualificado) externo da sua implantação do Azure Stack Hub para pontos de extremidade voltados para o público é a combinação desses dois nomes: <região>.<fqdn>. Por exemplo, east.cloud.fabrikam.com. Neste exemplo, os portais do Azure Stack Hub estariam disponíveis nas seguintes URLs:
https://portal.east.cloud.fabrikam.comhttps://adminportal.east.cloud.fabrikam.com
Importante
O nome da região escolhida para sua implantação do Azure Stack Hub deve ser exclusivo e aparecerá nos endereços do portal.
A tabela a seguir resume essas decisões de nomeação de domínio.
| Nome | Descrição |
|---|---|
| Nome da região | O nome da sua primeira região do Azure Stack Hub. Esse nome é usado como parte do FQDN para os endereços IP virtuais públicos (VIPs) que o Azure Stack Hub gerencia. Normalmente, o nome da região seria um identificador de local físico, como um local de datacenter. O nome da região deve consistir apenas em letras e números entre 0-9. Não são permitidos caracteres especiais (como -, #e assim por diante). |
| Nome de domínio externo | O nome da zona DNS (Sistema de Nomes de Domínio) para pontos de extremidade com VIPs voltados para o exterior. Usado no FQDN para estes VIPs públicos. |
| Nome de domínio privado (interno) | O nome do domínio (e zona DNS interna) criado no Azure Stack Hub para gerenciamento de infraestrutura. |
Requisitos de certificação
Para implementação, precisará fornecer certificados SSL (Secure Sockets Layer) para endpoints públicos. Em um alto nível, os certificados têm os seguintes requisitos:
- Você pode usar um único certificado wildcard ou um conjunto de certificados dedicados e, em seguida, usar wildcards apenas para pontos de extremidade, como armazenamento e o Cofre de Chaves.
- Os certificados podem ser emitidos por uma autoridade de certificação (CA) pública confiável ou por uma CA gerenciada pelo cliente.
Para obter mais informações sobre quais certificados PKI são necessários para implantar o Azure Stack Hub e como obtê-los, consulte Requisitos de certificado de Infraestrutura de Chave Pública do Azure Stack Hub.
Importante
As informações fornecidas sobre o certificado PKI devem ser utilizadas como orientação geral. Antes de adquirir qualquer certificado PKI para o Azure Stack Hub, trabalhe com seu parceiro de hardware OEM. Eles fornecerão orientações e requisitos de certificado mais detalhados.
Sincronização de tempo
Você deve escolher um servidor de horário específico que é usado para sincronizar o Azure Stack Hub. A sincronização de tempo é crítica para o Azure Stack Hub e suas funções de infraestrutura porque é usada para gerar tíquetes Kerberos. Os tíquetes Kerberos são usados para autenticar serviços internos entre si.
Você deve especificar um IP para o servidor de sincronização de tempo. Embora a maioria dos componentes na infraestrutura possa resolver uma URL, alguns suportam apenas endereços IP. Se estiver a utilizar a opção de implementação desligada, deve especificar um servidor de tempo na sua rede empresarial ao qual esteja certo de poder aceder a partir da rede de infraestrutura no Azure Stack Hub.
Importante
Se o seu servidor de tempo não for um servidor NTP baseado no Windows, precisará anexar ,0x8 ao final do endereço IP. Por exemplo, 10.1.1.123,0x8.
Conectar o Azure Stack Hub ao Azure
Para cenários de nuvem híbrida, você precisará planejar como deseja conectar o Azure Stack Hub ao Azure. Há dois métodos com suporte para conectar redes virtuais no Hub de Pilha do Azure a redes virtuais no Azure:
Site-to-site: Uma conexão de rede privada virtual (VPN) através do IPsec (IKE v1 e IKE v2). Esse tipo de conexão requer um dispositivo VPN ou RRAS (Serviço de Roteamento e Acesso Remoto). Para obter mais informações sobre gateways de VPN no Azure, consulte Sobre o Gateway de VPN. A comunicação através deste túnel é encriptada e segura. No entanto, a largura de banda é limitada pela taxa de transferência máxima do túnel (100-200 Mbps).
NAT de saída: Por padrão, todas as VMs no Azure Stack Hub terão conectividade com redes externas por meio de NAT de saída. Cada rede virtual criada no Azure Stack Hub recebe um endereço IP público atribuído a ela. Se a VM for diretamente atribuída um endereço IP público ou estiver atrás de um balanceador de carga com um endereço IP público, terá acesso externo via NAT de saída usando o IP Virtual (VIP) da rede virtual. Esse método só funciona para comunicação iniciada pela VM e destinada a redes externas (internet ou intranet). Ele não pode ser usado para se comunicar com a VM de fora.
Opções de conectividade híbrida
Para conectividade híbrida, é importante considerar que tipo de implantação você deseja oferecer e onde ela será implantada. Você precisará considerar se precisa isolar o tráfego de rede por locatário e se terá uma implantação de intranet ou Internet.
Azure Stack Hub de locatário único: uma implantação do Azure Stack Hub que parece, pelo menos de uma perspetiva de rede, como se fosse de um único locatário. Pode haver muitas assinaturas de locatário, mas, como qualquer serviço de intranet, todo o tráfego viaja pelas mesmas redes. O tráfego de rede de uma subscrição viaja através da mesma ligação de rede que outra subscrição e não precisa de ser isolado através de um túnel encriptado.
Azure Stack Hub Multilocatário: uma implantação do Azure Stack Hub em que o tráfego associado a cada assinatura de locatário destinado a redes externas ao Azure Stack Hub deve ser isolado do tráfego de rede de outros locatários.
Implantação da Intranet: uma implantação do Azure Stack Hub que se encontra numa intranet corporativa, geralmente em espaço de endereçamento IP privado e atrás de um ou mais firewalls. Os endereços IP públicos não são verdadeiramente públicos porque não podem ser encaminhados diretamente pela Internet pública.
Implantação da Internet: Uma implantação do Azure Stack Hub conectada à Internet pública e que usa endereços IP públicos roteáveis pela Internet para o intervalo de VIP público. A implantação ainda pode ficar atrás de um firewall, mas o intervalo VIP público é diretamente acessível a partir da Internet pública e do Azure.
A tabela a seguir resume os cenários de conectividade híbrida com os prós, contras e casos de uso.
| Cenário | Método de conectividade | Prós | Contras | Adequado para |
|---|---|---|---|---|
| Implantação de intranet do Azure Stack Hub para locatário único | NAT de saída | Melhor largura de banda para transferências mais rápidas. Simples de implementar; não são necessários gateways. | Tráfego não encriptado; Sem isolamento ou criptografia fora da pilha. | Implantações corporativas em que todos os locatários são igualmente confiáveis. Empresas que têm um circuito do Azure ExpressRoute para o Azure. |
| Azure Stack Hub multilocatário, implantação de intranet | VPN de site para site | O tráfego da VNet do locatário para o destino é seguro. | A largura de banda é limitada pelo túnel VPN site a site. Requer um gateway na rede virtual e um dispositivo VPN na rede de destino. |
Implantações corporativas em que algum tráfego de locatário deve ser protegido de outros locatários. |
| Implantação na Internet de Azure Stack Hub para locatário único | NAT de saída | Melhor largura de banda para transferências mais rápidas. | Tráfego não encriptado; Sem isolamento ou criptografia fora da pilha. | Cenários de hospedagem em que o locatário obtém sua própria implantação do Azure Stack Hub e um circuito dedicado ao ambiente do Azure Stack Hub. Por exemplo, ExpressRoute e Multiprotocol Label Switching (MPLS). |
| Azure Stack Hub multilocatário, implantação na Internet | VPN de site a site | O tráfego para o destino a partir da VNet do locatário é seguro. | A largura de banda é limitada pelo túnel VPN site a site. Requer um gateway na rede virtual e um dispositivo VPN na rede de destino. |
Cenários de hospedagem em que o provedor deseja oferecer uma nuvem multilocatário, onde os locatários não confiam uns nos outros e o tráfego deve ser criptografado. |
Usando a Rota Expressa
Você pode conectar o Azure Stack Hub ao Azure por meio de Rota Expressa para cenários de intranet de locatário único e multilocatário. Você precisará de um circuito de ExpressRoute provisionado através de um provedor de conectividade em.
O diagrama a seguir mostra o ExpressRoute para um cenário de inquilino único (onde "conexão do cliente" é o circuito ExpressRoute).
A diagrama a seguir mostra o ExpressRoute para um cenário multilocatário.
Monitorização externa
Para obter uma visão única de todos os alertas de sua implantação e dispositivos do Azure Stack Hub e para integrar alertas em fluxos de trabalho de Gerenciamento de Serviços de TI existentes para emissão de tíquetes, você pode integrar o Azure Stack Hub com soluções de monitoramento de datacenter externo.
Incluído na solução Azure Stack Hub, o host do ciclo de vida do hardware é um computador fora do Azure Stack Hub que executa ferramentas de gerenciamento de hardware fornecidas pelo fornecedor OEM. Você pode usar essas ferramentas ou outras soluções que se integram diretamente com as soluções de monitoramento existentes em seu datacenter.
A tabela a seguir resume a lista de opções atualmente disponíveis.
| Área | Solução de Monitorização Externa |
|---|---|
| Software Azure Stack Hub |
Pacote de Gerenciamento do Azure Stack Hub para Operations Manager Nagios plug-in Chamadas de API baseadas em REST |
| Servidores físicos (BMCs via IPMI) | Hardware OEM - Pacote de gerenciamento do fornecedor do Operations Manager Solução fornecida pelo fornecedor de hardware OEM Plug-ins de Nagios do fornecedor de hardware. Solução de monitoramento suportada por parceiros OEM (incluída) |
| Dispositivos de rede (SNMP) | Deteção de dispositivos de rede do Operations Manager Solução fornecida pelo fornecedor de hardware OEM Plug-in de switch Nagios |
| Monitorização da saúde da subscrição do inquilino | Pacote de Gerenciamento do System Center para Windows Azure |
Observe os seguintes requisitos:
- A solução que você usa deve ser sem agente. Não é possível instalar agentes de terceiros dentro dos componentes do Azure Stack Hub.
- Se você quiser usar o System Center Operations Manager, é necessário o Operations Manager 2012 R2 ou o Operations Manager 2016.
Backup e recuperação de desastres
O planejamento de backup e recuperação de desastres envolve o planejamento da infraestrutura subjacente do Azure Stack Hub que hospeda VMs IaaS e serviços PaaS e de aplicativos e dados do locatário. Planeje essas coisas separadamente.
Proteja os componentes da infraestrutura
Você pode fazer backup dos componentes de infraestrutura do Azure Stack Hub num compartilhamento SMB que você especificou:
- Você precisará de um compartilhamento de arquivos SMB externo em um servidor de arquivos baseado no Windows existente ou em um dispositivo de terceiros.
- Use esse mesmo compartilhamento para o backup de switches de rede e do host do ciclo de vida do hardware. Seu fornecedor de hardware OEM ajudará a fornecer orientação para backup e restauração desses componentes, pois eles são externos ao Azure Stack Hub. Você é responsável por executar os fluxos de trabalho de backup com base na recomendação do fornecedor OEM.
Se ocorrer uma perda de dados catastrófica, você poderá usar o backup de infraestrutura para redistribuir dados de implantação, como:
- Entradas e identificadores de implantação
- Contas de serviço
- Certificado raiz da autoridade de certificação
- Recursos federados (em implantações desconectadas)
- Planos, ofertas, subscrições e quotas
- Política RBAC e atribuições de funções
- Segredos do Key Vault
Advertência
Por padrão, seu carimbo do Azure Stack Hub é configurado com apenas uma conta CloudAdmin. Não há opções de recuperação se as credenciais da conta forem perdidas, comprometidas ou bloqueadas. Você perderá o acesso ao ponto de extremidade privilegiado e a outros recursos.
É altamente recomendável que você crie contas adicionais do CloudAdmin, para evitar a reimplantação do seu selo às suas próprias custas. Certifique-se de documentar essas credenciais com base nas diretrizes da sua empresa.
Proteja aplicativos locatários em VMs IaaS
O Azure Stack Hub não faz backup de aplicativos e dados de locatário. Você deve planejar a proteção de backup e recuperação de desastres para um destino externo ao Azure Stack Hub. A proteção do inquilino é uma atividade orientada pelo inquilino. Para VMs IaaS, os locatários podem usar tecnologias de convidado para proteger pastas de arquivos, dados de aplicativos e o estado do sistema. No entanto, como uma empresa ou provedor de serviços, você pode querer oferecer uma solução de backup e recuperação no mesmo datacenter ou externamente em uma nuvem.
Para fazer backup de VMs IaaS Linux ou Windows, você deve usar produtos de backup com acesso ao sistema operacional convidado para proteger dados de arquivos, pastas, sistemas operacionais e aplicativos. Você pode usar o Backup do Azure, o System Center Datacenter Protection Manager ou produtos de terceiros com suporte.
Para replicar dados para um local secundário e orquestrar o failover de aplicativos se ocorrer um desastre, você pode usar o Azure Site Recovery ou produtos de terceiros com suporte. Além disso, os aplicativos que oferecem suporte à replicação nativa, como o Microsoft SQL Server, podem replicar dados para outro local onde o aplicativo está sendo executado.
Saiba mais
- Para obter informações sobre casos de uso, compras, parceiros e fornecedores de hardware OEM, consulte a página do produto do Azure Stack Hub.
- Para obter informações sobre o roteiro e a disponibilidade geográfica para sistemas integrados do Azure Stack Hub, consulte o white paper: Azure Stack Hub: Uma extensão do Azure.