Considerações de planeamento da integração do Datacenter para sistemas integrados do Azure Stack Hub

Se estiver interessado num sistema integrado do Azure Stack Hub, deve compreender as principais considerações de planeamento sobre a implementação e como o sistema se encaixa no seu datacenter. Este artigo fornece uma descrição geral de alto nível destas considerações para ajudá-lo a tomar decisões de infraestrutura importantes para os seus sistemas integrados do Azure Stack Hub. Uma compreensão destas considerações ajuda ao trabalhar com o fornecedor de hardware OEM enquanto implementa o Azure Stack Hub no seu datacenter.

Nota

Os sistemas integrados do Azure Stack Hub só podem ser comprados a fornecedores de hardware autorizados.

Para implementar o Azure Stack Hub, tem de fornecer informações de planeamento ao seu fornecedor de soluções antes de a implementação começar a ajudar o processo a funcionar de forma rápida e suave. As informações necessárias variam entre redes, segurança e informações de identidade com muitas decisões importantes que podem exigir conhecimento de várias áreas e decisores diferentes. Precisará de pessoas de várias equipas na sua organização para garantir que tem todas as informações necessárias prontas antes da implementação. Pode ajudar a falar com o fornecedor de hardware enquanto recolhe estas informações, uma vez que podem ter conselhos úteis.

Ao pesquisar e recolher as informações necessárias, poderá ter de fazer algumas alterações à configuração de pré-implementação no seu ambiente de rede. Estas alterações podem incluir a reserva de espaços de endereços IP para a solução do Azure Stack Hub, bem como a configuração dos routers, comutadores e firewalls para se prepararem para a conectividade aos novos comutadores de solução do Azure Stack Hub. Certifique-se de que tem o especialista em área de assunto alinhado para ajudá-lo com o seu planeamento.

Considerações sobre o planeamento de capacidade

Quando avalia uma solução do Azure Stack Hub para aquisição, faz escolhas de configuração de hardware que têm um impacto direto na capacidade global da solução do Azure Stack Hub. Estas incluem as opções clássicas de CPU, densidade de memória, configuração de armazenamento e escala global de soluções (por exemplo, número de servidores). Ao contrário de uma solução de virtualização tradicional, a aritmética simples destes componentes para determinar a capacidade utilizável não se aplica. A primeira razão é que o Azure Stack Hub está arquitetado para alojar a infraestrutura ou os componentes de gestão na própria solução. A segunda razão é que algumas das capacidades da solução estão reservadas em suporte de resiliência ao atualizar o software da solução de forma a minimizar a interrupção das cargas de trabalho do inquilino.

A folha de cálculo do planeador de capacidade do Azure Stack Hub ajuda-o a tomar decisões informadas para planear a capacidade de duas formas. A primeira é selecionar uma oferta de hardware e tentar ajustar uma combinação de recursos. A segunda é definir a carga de trabalho que o Azure Stack Hub se destina a executar para ver os SKUs de hardware disponíveis que o podem suportar. Por fim, a folha de cálculo destina-se a ser um guia para ajudar a tomar decisões relacionadas com o planeamento e configuração do Azure Stack Hub.

A folha de cálculo não se destina a servir de substituto para a sua própria investigação e análise. A Microsoft não faz representações ou garantias, expressas ou implícitas, relativamente às informações fornecidas na folha de cálculo.

Considerações sobre gestão

O Azure Stack Hub é um sistema selado, onde a infraestrutura está bloqueada tanto a partir de uma perspetiva de rede como de permissões. As listas de controlo 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 componentes de infraestrutura. Este sistema dificulta o acesso dos utilizadores não autorizados ao sistema.

Para gestão e operações diárias, não existe acesso de administrador sem restrições à infraestrutura. Os operadores do Azure Stack Hub têm de gerir o sistema através do portal de administrador ou através do Azure Resource Manager (através do PowerShell ou da API REST). Não existe acesso ao sistema por outras ferramentas de gestão, como o Gestor de Hyper-V ou o Gestor de Clusters de Ativação Pós-falha. Para ajudar a proteger o sistema, não é possível instalar software de terceiros (por exemplo, agentes) dentro dos componentes da infraestrutura do Azure Stack Hub. A interoperabilidade com a gestão externa e o software de segurança ocorre através do PowerShell ou da API REST.

Contacte Suporte da Microsoft quando precisar de um nível de acesso mais elevado para resolver problemas que não são resolvidos através dos passos de mediação de alertas. Através do suporte, existe um método para fornecer acesso de administrador completo temporário ao sistema para operações mais avançadas.

Considerações de identidade

Escolher fornecedor de identidade

Terá de considerar o fornecedor de identidade que pretende utilizar para a implementação do Azure Stack Hub, Microsoft Entra ID ou AD FS. Não pode mudar de fornecedor de identidade após a implementação sem a reimplementaçã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 Cloud e se decidir mudar de fornecedor e utilizar uma conta Microsoft Entra diferente, terá de contactar o fornecedor de soluções para reimplementar a solução a seu custo.

A escolha do fornecedor de identidade não tem qualquer influência nas máquinas virtuais de inquilino (VMs), no sistema de identidade, nas contas que utilizam ou se podem aderir a um domínio do Active Directory, etc. Estas coisas são separadas.

Pode implementar vários sistemas do Azure Stack Hub com o mesmo inquilino Microsoft Entra ou o Active Directory.

Integração do AD FS e do Graph

Se optar por implementar o Azure Stack Hub com o AD FS como fornecedor de identidade, tem de integrar a instância do AD FS no Azure Stack Hub com uma instância do AD FS existente através de uma confiança de federação. Esta integração permite que as identidades numa floresta existente do Active Directory se autentiquem com recursos no Azure Stack Hub.

Também pode integrar o serviço Graph no Azure Stack Hub com o Active Directory existente. Esta integração permite-lhe gerir Role-Based Controlo de Acesso (RBAC) no Azure Stack Hub. Quando o acesso a um recurso é delegado, o componente do Graph procura a conta de utilizador na floresta existente do Active Directory com o protocolo LDAP.

O diagrama seguinte mostra o fluxo de tráfego integrado do AD FS e do Graph.

Modelo de licenciamento

Tem de decidir que modelo de licenciamento pretende utilizar. As opções disponíveis dependem se implementar o Azure Stack Hub ligado à Internet:

• Para uma implementação ligada, pode escolher o licenciamento pay as you use ou baseado em capacidade. O pay as you use requer uma ligação ao Azure para comunicar a utilização, que é faturada através do comércio do Azure.
• Apenas o licenciamento baseado na capacidade é suportado se implementar desligado da Internet.

Para obter mais informações sobre os modelos de licenciamento, veja Empacotamento e preços do Microsoft Azure Stack Hub.

Nomenclatura de decisões

Terá de pensar em como pretende planear o espaço de nomes do Azure Stack Hub, especialmente o nome da região e o nome de domínio externo. O nome de domínio completamente qualificado externo (FQDN) da implementação do Azure Stack Hub para pontos finais destinados ao público é a combinação destes dois nomes: <região>.<fqdn>. Por exemplo, east.cloud.fabrikam.com. Neste exemplo, os portais do Azure Stack Hub estariam disponíveis nos seguintes URLs:

• https://portal.east.cloud.fabrikam.com
• https://adminportal.east.cloud.fabrikam.com

Importante

O nome da região que escolher para a implementação do Azure Stack Hub tem de ser exclusivo e aparecerá nos endereços do portal.

A tabela seguinte resume estas decisões de nomenclatura de domínio.

Nome	Descrição
Nome da região	O nome da sua primeira região do Azure Stack Hub. Este nome é utilizado como parte do FQDN para os endereços IP virtuais públicos (VIPs) geridos pelo Azure Stack Hub. Normalmente, o nome da região seria um identificador de localização física, como uma localização do datacenter. O nome da região tem de consistir apenas em letras e números entre 0 e 9. Não são permitidos carateres especiais (como -, #, etc.).
Nome de domínio externo	O nome da zona DNS (Domain Name System) para pontos finais com VIPs com acesso externo. Utilizado no FQDN para estes VIPs públicos.
Nome de domínio privado (interno)	O nome do domínio (e da zona DNS interna) criado no Azure Stack Hub para gestão de infraestruturas.

Requisitos de certificados

Para a implementação, terá de fornecer certificados SSL (Secure Sockets Layer) para pontos finais destinados ao público. A um nível elevado, os certificados têm os seguintes requisitos:

• Pode utilizar um único certificado de caráter universal ou utilizar um conjunto de certificados dedicados e, em seguida, utilizar carateres universais apenas para pontos finais, como armazenamento e Key Vault.
• Os certificados podem ser emitidos por uma autoridade pública de certificação fidedigna (AC) ou por uma AC gerida pelo cliente.

Para obter mais informações sobre os certificados PKI necessários para implementar o Azure Stack Hub e como os obter, veja Requisitos de certificados da Infraestrutura de Chaves Públicas do Azure Stack Hub.

Importante

As informações de certificado PKI fornecidas devem ser utilizadas como orientação geral. Antes de adquirir certificados PKI para o Azure Stack Hub, trabalhe com o seu parceiro de hardware do OEM. Fornecerão orientações e requisitos de certificados mais detalhados.

Sincronização de hora

Tem de escolher um servidor de hora específico que seja utilizado para sincronizar o Azure Stack Hub. A sincronização de tempo é fundamental para o Azure Stack Hub e as respetivas funções de infraestrutura, uma vez que é utilizada para gerar pedidos Kerberos. Os bilhetes Kerberos são utilizados para autenticar serviços internos entre si.

Tem de especificar um IP para o servidor de sincronização de tempo. Embora a maioria dos componentes na infraestrutura possa resolver um URL, alguns suportam apenas endereços IP. Se estiver a utilizar a opção de implementação desligada, tem de especificar um servidor de tempo na sua rede empresarial que tenha a certeza de que consegue aceder a partir da rede de infraestrutura no Azure Stack Hub.

Importante

Se o servidor de tempo não for um servidor NTP baseado no Windows, terá de acrescentar ,0x8 o fim do endereço IP. Por exemplo, 10.1.1.123,0x8.

Ligar o Azure Stack Hub ao Azure

Para cenários de cloud híbrida, terá de planear como pretende ligar o Azure Stack Hub ao Azure. Existem dois métodos suportados para ligar redes virtuais no Azure Stack Hub a redes virtuais no Azure:

• Site a site: uma ligação de rede privada virtual (VPN) através de IPsec (IKE v1 e IKE v2). Este tipo de ligação requer um dispositivo VPN ou o Serviço de Encaminhamento e Acesso Remoto (RRAS). Para obter mais informações sobre gateways de VPN no Azure, veja Acerca de Gateway de VPN. A comunicação através deste túnel é encriptada e segura. No entanto, a largura de banda é limitada pelo débito máximo do túnel (100-200 Mbps).

• NAT de saída: por predefinição, todas as VMs no Azure Stack Hub terão conectividade a redes externas através de NAT de saída. Cada rede virtual criada no Azure Stack Hub recebe um endereço IP público atribuído à mesma. Quer a VM tenha atribuído diretamente um endereço IP público ou esteja atrás de um balanceador de carga com um endereço IP público, terá acesso de saída através do NAT de saída com o VIP da rede virtual. Este método só funciona para comunicação iniciada pela VM e destinada a redes externas (internet ou intranet). Não pode ser utilizado para comunicar com a VM de fora.

Opções de conectividade híbrida

Para conectividade híbrida, é importante considerar que tipo de implementação pretende oferecer e onde será implementada. Terá de considerar se precisa de isolar o tráfego de rede por inquilino e se terá uma intranet ou uma implementação na Internet.

• Azure Stack Hub de inquilino único: uma implementação do Azure Stack Hub que parece, pelo menos, do ponto de vista da rede, como se fosse um inquilino. Pode haver muitas subscrições de inquilinos, mas, como qualquer serviço de intranet, todo o tráfego viaja pelas mesmas redes. O tráfego de rede de uma subscrição percorre a mesma ligação de rede que outra subscrição e não precisa de ser isolado através de um túnel encriptado.

• Multi-inquilino do Azure Stack Hub: uma implementação do Azure Stack Hub onde o tráfego de cada subscrição de inquilino com destino a redes externas ao Azure Stack Hub tem de estar isolado do tráfego de rede de outros inquilinos.

• Implementação da intranet: uma implementação do Azure Stack Hub que se encontra numa intranet empresarial, normalmente num espaço de endereços IP privado e atrás de uma ou mais firewalls. Os endereços IP públicos não são verdadeiramente públicos porque não podem ser encaminhados diretamente através da Internet pública.

• Implementação da Internet: uma implementação do Azure Stack Hub que está ligada à Internet pública e utiliza endereços IP públicos encaminháveis pela Internet para o intervalo vip público. A implementação ainda pode ficar atrás de uma firewall, mas o intervalo vip público está diretamente acessível a partir da Internet pública e do Azure.

A tabela seguinte resume os cenários de conectividade híbrida com os pros, os contras e os casos de utilização.

Scenario	Método de Conectividade	Vantagens	Desvantagens	Bom para
Inquilino único do Azure Stack Hub, implementação da intranet	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 encriptação fora da pilha.	Implementações empresariais em que todos os inquilinos são igualmente fidedignos. Empresas que têm um circuito do Azure ExpressRoute para o Azure.
Multi-inquilino do Azure Stack Hub, implementação da intranet	VPN site a site	O tráfego da VNet do inquilino 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.	Implementações empresariais em que algum tráfego de inquilino tem de ser protegido de outros inquilinos.
Inquilino único do Azure Stack Hub, implementação da Internet	NAT de saída	Melhor largura de banda para transferências mais rápidas.	Tráfego não encriptado; sem isolamento ou encriptação fora da pilha.	Cenários de alojamento em que o inquilino obtém a sua própria implementação do Azure Stack Hub e um circuito dedicado para o ambiente do Azure Stack Hub. Por exemplo, Comutador de Etiquetas ExpressRoute e Multiprotocol (MPLS).
Multi-inquilino do Azure Stack Hub, implementação da Internet	VPN site a site	O tráfego da VNet do inquilino 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.	Cenários de alojamento em que o fornecedor quer oferecer uma cloud multi-inquilino, em que os inquilinos não confiam uns nos outros e o tráfego tem de ser encriptado.

Utilizar o ExpressRoute

Pode ligar o Azure Stack Hub ao Azure através do ExpressRoute para cenários de intranet de inquilino único e multi-inquilino. Precisará de um circuito expressRoute aprovisionado através de um fornecedor de conectividade.

O diagrama seguinte mostra o ExpressRoute para um cenário de inquilino único (em que "Ligação do cliente" é o circuito do ExpressRoute).

O diagrama seguinte mostra o ExpressRoute para um cenário multi-inquilino.

Monitorização externa

Para obter uma única vista de todos os alertas da implementação e dispositivos do Azure Stack Hub e para integrar alertas em fluxos de trabalho de Gestão de Serviços de TI existentes para suporte de pedidos de suporte, pode integrar o Azure Stack Hub com soluções de monitorização de datacenters externos.

Incluído na solução do Azure Stack Hub, o anfitrião do ciclo de vida do hardware é um computador fora do Azure Stack Hub que executa ferramentas de gestão fornecidas pelo fornecedor OEM para hardware. Pode utilizar estas ferramentas ou outras soluções que se integram diretamente com soluções de monitorização existentes no seu datacenter.

A tabela seguinte resume a lista de opções atualmente disponíveis.

Área	Solução de Monitorização Externa
Software do Azure Stack Hub	Pacote de Gestão do Azure Stack Hub para o Operations Manager Plug-in nagios Chamadas à API baseadas em REST
Servidores físicos (BMCs através de IPMI)	Hardware OEM - Pacote de gestão de fornecedores do Operations Manager Solução fornecida pelo fornecedor de hardware OEM Plug-ins do fornecedor de hardware Nagios. Solução de monitorização suportada pelo parceiro 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 do comutador Nagios
Monitorização do estado de funcionamento da subscrição do inquilino	Pacote de Gestão do System Center para Windows Azure

Tenha em atenção os seguintes requisitos:

• A solução que utiliza tem de ser sem agente. Não pode instalar agentes de terceiros dentro dos componentes do Azure Stack Hub.
• Se quiser utilizar o System Center Operations Manager, é necessário o Operations Manager 2012 R2 ou o Operations Manager 2016.

Cópia de segurança e recuperação após desastre

Planear a cópia de segurança e a recuperação após desastre envolve o planeamento da infraestrutura subjacente do Azure Stack Hub que aloja VMs IaaS e serviços PaaS e para aplicações e dados de inquilinos. Planeie estas coisas separadamente.

Protect infrastructure components (Proteger os componentes da infraestrutura)

Pode fazer uma cópia de segurança dos componentes da infraestrutura do Azure Stack Hub para uma partilha SMB que especificar:

• Precisará de uma partilha de ficheiros SMB externa num servidor de ficheiros baseado no Windows existente ou num dispositivo de terceiros.
• Utilize esta mesma partilha para a cópia de segurança de comutadores de rede e o anfitrião do ciclo de vida do hardware. O fornecedor de hardware do OEM irá ajudar a fornecer orientações para a cópia de segurança e restauro destes componentes, uma vez que estes são externos ao Azure Stack Hub. É responsável por executar os fluxos de trabalho de cópia de segurança com base na recomendação do fornecedor do OEM.

Se ocorrer uma perda catastrófica de dados, pode utilizar a cópia de segurança da infraestrutura para reutilizar dados de implementação, tais como:

• Entradas e identificadores de implementação
• Contas de serviço
• Certificado de raiz da AC
• Recursos federados (em implementações desligadas)
• Planos, ofertas, subscrições e quotas
• Atribuições de funções e políticas RBAC
• segredos de Key Vault

Aviso

Por predefinição, o carimbo do Azure Stack Hub está configurado com apenas uma conta cloudAdmin. Não existem opções de recuperação se as credenciais da conta forem perdidas, comprometidas ou bloqueadas. Perderá o acesso ao ponto final privilegiado e a outros recursos.

Recomenda-se vivamente que crie contas cloudAdmin adicionais para evitar a reimplementação do seu selo às suas próprias custas. Certifique-se de que documenta estas credenciais com base nas diretrizes da sua empresa.

Proteger aplicações de inquilino em VMs IaaS

O Azure Stack Hub não faz cópias de segurança de aplicações e dados de inquilinos. Tem de planear a proteção contra cópias de segurança e recuperação após desastre para um destino externo ao Azure Stack Hub. A proteção de inquilinos é uma atividade orientada pelo inquilino. Para VMs IaaS, os inquilinos podem utilizar tecnologias no convidado para proteger pastas de ficheiros, dados de aplicações e estado do sistema. No entanto, enquanto empresa ou fornecedor de serviços, poderá querer oferecer uma solução de cópia de segurança e recuperação no mesmo datacenter ou externamente numa cloud.

Para fazer uma cópia de segurança das VMs IaaS do Linux ou do Windows, tem de utilizar produtos de cópia de segurança com acesso ao sistema operativo convidado para proteger ficheiros, pastas, estado do sistema operativo e dados de aplicações. Pode utilizar Azure Backup, o System Center Datacenter Protection Manager ou produtos de terceiros suportados.

Para replicar dados para uma localização secundária e orquestrar a ativação pós-falha da aplicação se ocorrer um desastre, pode utilizar o Azure Site Recovery ou produtos de terceiros suportados. Além disso, as aplicações que suportam a replicação nativa, como o Microsoft SQL Server, podem replicar dados para outra localização onde a aplicação está em execução.

Saber mais

• Para obter informações sobre casos de utilização, compras, parceiros e fornecedores de hardware OEM, veja a página de produtos do Azure Stack Hub .
• Para obter informações sobre o mapa de objetivos e a disponibilidade geográfica dos sistemas integrados do Azure Stack Hub, veja o documento técnico: Azure Stack Hub: Uma extensão do Azure.

Passos seguintes

Modelos de ligação de implementação do Azure Stack Hub