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

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

Nota

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

Para implementar o Azure Stack Hub, precisa de fornecer informações de planeamento ao seu fornecedor de soluções antes de começar a implantação para ajudar o processo a funcionar de forma rápida e suave. A informação necessária abrange toda a informação de networking, segurança e identidade com muitas decisões importantes que podem exigir conhecimento de muitas áreas e decisores diferentes. Vai precisar de pessoas de várias equipas da sua organização para garantir que todas as informações necessárias estão prontas antes da sua implantação. Pode ajudar a falar com o seu fornecedor de hardware enquanto recolhe esta informação porque podem ter conselhos úteis.

Ao pesquisar e recolher as informações necessárias, poderá necessitar de fazer algumas alterações de configuração pré-implantação no ambiente da sua rede. Estas alterações podem incluir a reserva de espaços de endereço IP para a solução Azure Stack Hub, bem como configurar os seus routers, interruptores e firewalls para se prepararem para a conectividade com os novos comutadores de solução Azure Stack Hub. Certifique-se de ter o perito em área de assunto alinhado para ajudá-lo com o seu planeamento.

Considerações sobre o planeamento de capacidade

Ao avaliar uma solução 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 Azure Stack Hub. Estas incluem as escolhas clássicas de CPU, densidade de memória, configuração de armazenamento e escala geral de solução (por exemplo, número de servidores). Ao contrário de uma solução de virtualização tradicional, a simples aritmética destes componentes para determinar a capacidade utilizável não se aplica. A primeira razão é que o Azure Stack Hub é projetado para acolher a infraestrutura ou componentes de gestão dentro da própria solução. A segunda razão é que algumas das capacidades da solução são reservadas em apoio à resiliência, atualizando o software da solução de forma a minimizar a perturbação das cargas de trabalho dos inquilinos.

A folha de planificação de capacidade do Azure Stack Hub ajuda-o a tomar decisões informadas para a capacidade de planeamento de duas maneiras. A primeira é selecionando uma oferta de hardware e tentando encaixar uma combinação de recursos. A segunda é definir a carga de trabalho que o Azure Stack Hub pretende executar para ver os SKUs de hardware disponíveis que podem apoiá-lo. Finalmente, a folha de cálculo destina-se a ajudar a tomar decisões relacionadas com o planeamento e configuração do Azure Stack Hub.

A folha de cálculo não serve como substituto da sua própria investigação e análise. A Microsoft não faz nenhuma representação ou garantia, expressa ou implícita, no que diz respeito às informações fornecidas dentro da folha de cálculo.

Considerações sobre gestão

O Azure Stack Hub é um sistema selado, onde a infraestrutura é bloqueada tanto a partir de uma perspetiva de permissões como de rede. 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 de utilizadores não autorizados ao sistema.

Para gestão e operações diárias, não há acesso administrativo ilimitado à infraestrutura. Os operadores do Azure Stack Hub devem gerir o sistema através do portal do administrador ou através do Azure Resource Manager (via PowerShell ou da API REST). Não há acesso ao sistema por outras ferramentas de gestão como Hyper-V Manager ou Failover Cluster Manager. Para ajudar a proteger o sistema, o software de terceiros (por exemplo, agentes) não pode ser instalado dentro dos componentes da infraestrutura Azure Stack Hub. A interoperabilidade com software de gestão e segurança externo ocorre através do PowerShell ou da REST API.

Contacte o Microsoft Support quando necessitar de um nível de acesso mais elevado para problemas de resolução de problemas que não sejam resolvidos através de medidas de mediação de alerta. Através do apoio, existe um método para fornecer acesso temporário ao sistema para operações mais avançadas.

Considerações de identidade

Escolha o fornecedor de identidade

Você terá de considerar que fornecedor de identidade pretende usar para a implementação do Azure Stack Hub, seja a Azure AD ou AD FS. Não é possível trocar os fornecedores de identidade após a implementação sem a redistribuição completa do sistema. Se não possuir a conta Azure AD e estiver a utilizar uma conta fornecida pelo seu Fornecedor de Soluções em Nuvem, e se decidir mudar de fornecedor e utilizar uma conta AD Azure diferente, terá de contactar o seu fornecedor de soluções para lhe recolocar a solução a seu custo.

A sua escolha de fornecedor de identidade não tem qualquer influência nas máquinas virtuais do arrendatário (VMs), no sistema de identidade, nas contas que utilizam, ou se podem aderir a um domínio ative directory, e assim por diante. Estas coisas são separadas.

Você pode implementar vários sistemas Azure Stack Hub com o mesmo inquilino Azure Ative Directory ou Ative Directory.

Integração de FS AD e Graph

Se optar por implementar o Azure Stack Hub utilizando o AD FS como fornecedor de identidade, deve integrar a instância AD FS no Azure Stack Hub com uma instância AD FS existente através de um fundo de federação. Esta integração permite que identidades numa floresta de Ative Directory existente autensem com recursos no Azure Stack Hub.

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

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

Diagrama mostrando AD FS e Graph fluxo de tráfego

Modelo de licenciamento

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

  • Para uma implementação conectada,pode escolher o licenciamento baseado no pagamento ou na capacidade. Pay-as-you-use requer uma ligação com a Azure para reportar o uso, que é então cobrado através do comércio Azure.
  • Apenas o licenciamento baseado na capacidade é suportado se implementar desligado da internet.

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

Decisões de nomeação

Você precisa pensar em como você quer planear o seu espaço de nome Azure Stack Hub, especialmente o nome da região e o nome de domínio externo. O nome de domínio externo totalmente qualificado (FQDN) da sua implantação do Azure Stack Hub para pontos finais virados para o público é a combinação destes dois nomes: <<> . <>> . Por exemplo, east.cloud.fabrikam.com. Neste exemplo, os portais 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 sua implantação do Azure Stack Hub deve ser único e aparecerá nos endereços do portal.

A tabela que se segue resume estas 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. Este nome é usado como parte do FQDN para os endereços IP virtuais públicos (VIPs) que o Azure Stack Hub gere. Tipicamente, o nome da região seria um identificador de localização física, 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 do Sistema de Nome de Domínio (DNS) para pontos finais com VIPs virados para o exterior. Usado na FQDN para estes VIPs públicos.
Nome de domínio privado (interno) O nome do domínio (e zona de DNS interno) criado no Azure Stack Hub para gestão de infraestruturas.

Requisitos de certificados

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

  • Você pode usar um único certificado wildcard ou você pode usar um conjunto de certificados dedicados, e em seguida, usar wildcards apenas para pontos finais como armazenamento e Key Vault.
  • Os certificados podem ser emitidos por uma autoridade de certificados de confiança pública (CA) ou por uma AC gerida pelo cliente.

Para obter mais informações sobre quais os certificados PKI necessários para implantar o Azure Stack Hub, e como obtê-los, consulte, requisitos de certificado de infraestrutura de chaves públicas Azure Stack Hub.

Importante

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

Sincronização de hora

Tem de escolher um servidor de tempo específico que seja utilizado para sincronizar o Azure Stack Hub. A sincronização do tempo é fundamental para o Azure Stack Hub e para os seus papéis de infraestrutura porque é usado para gerar bilhetes Kerberos. Os bilhetes Kerberos são usados para autenticar serviços internos uns com os outros.

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

Importante

Se o seu servidor de tempo não for um servidor NTP baseado em Windows, tem de anexar ,0x8 o fim do endereço IP. Por exemplo, 10.1.1.123,0x8.

Ligação Azure Stack Hub para Azure

Para cenários de nuvem 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 em Azure:

  • Site-to-site: Uma ligação virtual de rede privada (VPN) sobre o IPsec (IKE v1 e IKE v2). Este tipo de ligação requer um dispositivo VPN ou Serviço de Encaminhamento e Acesso Remoto (RRAS). Para mais informações sobre gateways VPN em Azure, consulte About VPN Gateway. A comunicação sobre este túnel é encriptada e segura. No entanto, a largura de banda é limitada pela produção máxima do túnel (100-200 Mbps).

  • OUTBOUND NAT: Por padrão, todos os VMs no Azure Stack Hub terão conectividade com redes externas através de NAT de saída. Cada rede virtual criada no Azure Stack Hub obtém um endereço IP público atribuído. Se o VM é diretamente atribuído um endereço IP público ou está por trás de um equilibrador de carga com um endereço IP público, terá acesso de saída via OUT NAT utilizando o VIP da rede virtual. Este método funciona apenas para comunicação iniciada pelo VM e destinada a redes externas (internet ou intranet). Não pode ser usado para comunicar com o VM de fora.

Opções de conectividade híbrida

Para a conectividade híbrida, é importante considerar que tipo de implementação pretende oferecer e onde será implantada. Você terá que considerar se você precisa isolar o tráfego de rede por inquilino, e se você terá uma intranet ou uma implementação de internet.

  • Single-tenant Azure Stack Hub: Uma implantação do Azure Stack Hub que parece, pelo menos do ponto de vista de networking, como se fosse um inquilino. Pode haver muitas subscrições de inquilinos, mas como qualquer serviço 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.

  • Multi-inquilino Azure Stack Hub: Uma implantação do Azure Stack Hub onde o tráfego de cada subscrição de inquilinos que está ligado a redes externas ao Azure Stack Hub deve ser isolado do tráfego de rede de outros inquilinos.

  • Implementação intranet: Uma implantação do Azure Stack Hub que se encontra numa intranet corporativa, tipicamente no espaço de endereço 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 para a 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 de encaminhamento de internet para a gama VIP pública. A implementação ainda pode sentar-se atrás de uma firewall, mas a gama VIP pública é diretamente acessível a partir da internet pública e Azure.

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

Scenario Método de Conectividade Vantagens Desvantagens Bom para
Único inquilino Azure Stack Hub, implantação intranet NAT de saída Melhor largura de banda para transferências mais rápidas. Simples de implementar; não são necessários portais. Tráfego não encriptado; sem isolamento ou encriptação fora da pilha. Implantações empresariais onde todos os inquilinos são igualmente confiáveis.

Empresas que têm um circuito Azure ExpressRoute para Azure.
Multi-inquilino Azure Stack Hub, implantação intranet VPN site a site O tráfego do inquilino VNet para o destino é seguro. A largura de banda é limitada pelo túnel VPN local-a-local.

Requer uma porta de entrada na rede virtual e um dispositivo VPN na rede de destino.
Deslocações empresariais onde algum tráfego de inquilinos deve ser assegurado de outros inquilinos.
Inquilino Único Azure Stack Hub, implementação de 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. Hospedar cenários onde o inquilino obtém a sua própria implantação do Azure Stack Hub e um circuito dedicado ao ambiente Azure Stack Hub. Por exemplo, Comutação de etiquetas ExpressRoute e Multiprotocol (MPLS).
Multi-inquilino Azure Stack Hub, implementação de internet VPN site a site O tráfego do inquilino VNet para o destino é seguro. A largura de banda é limitada pelo túnel VPN local-a-local.

Requer uma porta de entrada na rede virtual e um dispositivo VPN na rede de destino.
Cenários de hospedagem onde o provedor quer oferecer uma nuvem multi-inquilino, onde os inquilinos não confiam uns nos outros e o tráfego deve ser encriptado.

Utilização do ExpressRoute

Você pode ligar Azure Stack Hub a Azure via ExpressRoute para cenários intranet de inquilino único e multi-inquilinos. Você precisará de um circuito ExpressRoute provisionado através de um provedor de conectividade.

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

Diagrama mostrando cenário expressRoute de inquilino único

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

Diagrama mostrando cenário expressRoute multi-inquilino

Monitorização externa

Para obter uma única visão de todos os alertas da sua implementação e dispositivos Azure Stack Hub, e para integrar alertas nos fluxos de trabalho existentes de Gestão de Serviços de TI para bilhética, pode integrar o Azure Stack Hub com soluções de monitorização de datacenters externas.

Incluído com a solução Azure Stack Hub, o anfitrião do ciclo de vida de 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 integrem diretamente com as soluções de monitorização existentes no seu datacenter.

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

Área Solução de Monitorização Externa
Software Azure Stack Hub Pacote de gestão de hub de pilha de Azure para gerente de operações
Nagios plug-in
Chamadas de API baseadas em REPOUSO
Servidores físicos (BMCs via IPMI) Hardware OEM - Pacote de gestão de fornecedores do Gestor de Operações
Solução fornecida pelo fornecedor de hardware OEM
Plug-ins do fornecedor de hardware Nagios.
Solução de monitorização apoiada por parceiros da OEM (incluída)
Dispositivos de rede (SNMP) Descoberta de dispositivos de rede de gestor de operações
Solução fornecida pelo fornecedor de hardware OEM
Plug-in de switch Nagios
Monitorização de saúde por assinatura de inquilino Pacote de gestão de System Center para Windows Azure

Note os seguintes requisitos:

  • A solução que usa deve ser sem agente. Não é possível instalar agentes de terceiros dentro dos componentes do Azure Stack Hub.
  • Se pretender utilizar System Center Gestor de Operações, é necessário o Gestor de Operações 2012 R2 ou o Gestor de Operações 2016.

Backup e recuperação de desastres

O planeamento para backup e recuperação de desastres envolve o planeamento tanto para a infraestrutura subjacente do Azure Stack Hub que acolhe serviços IaaS VMs e PaaS, como para aplicações e dados de inquilinos. Planeie estas coisas separadamente.

Protect infrastructure components (Proteger os componentes da infraestrutura)

Pode apoiar os componentes de infraestrutura do Azure Stack Hub numa partilha SMB que especifica:

  • Você precisará de uma partilha de ficheiro SMB externa num servidor de ficheiros baseado em Windows existente ou num dispositivo de terceiros.
  • Utilize esta mesma partilha para a cópia de segurança dos interruptores de rede e do anfitrião do ciclo de vida do hardware. O seu fornecedor de hardware OEM ajudará a fornecer orientação para a cópia de segurança e restauro destes componentes, uma vez que estes são externos ao Azure Stack Hub. É responsável pela execução dos fluxos de trabalho de backup com base na recomendação do fornecedor OEM.

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

  • Entradas e identificadores de implantação
  • Contas de serviço
  • Certificado de raiz ca
  • Recursos federados (em implantações desligadas)
  • Planos, ofertas, subscrições e quotas
  • Rbac política e atribuições de funções
  • Segredos do Cofre Chave

Proteja aplicativos de inquilinos em IaaS VMs

O Azure Stack Hub não faz o back up apps e dados dos inquilinos. Tem de planear a proteção de backup e recuperação de desastres para um alvo externo ao Azure Stack Hub. A proteção dos inquilinos é uma atividade orientada para os inquilinos. Para os IaaS VMs, os inquilinos podem usar tecnologias in-guest para proteger pastas de ficheiros, dados de aplicações e estado do sistema. No entanto, como empresa ou prestador de serviços, poderá querer oferecer uma solução de backup e recuperação no mesmo datacenter ou externamente numa nuvem.

Para fazer backup do Linux ou Windows IaaS VMs, tem de utilizar produtos de backup com acesso ao sistema operativo dos hóspedes para proteger ficheiros, pastas, estado do sistema operativo e dados de aplicações. Pode utilizar O Azure Backup, System Center Datacenter Protection Manager ou produtos de terceiros suportados.

Para replicar dados para uma localização secundária e orquestrar a falha da aplicação em caso de desastre, pode utilizar a Recuperação do Local de Azure ou produtos de terceiros suportados. Além disso, as aplicações que suportam a replicação nativa, como Microsoft SQL Server, podem replicar dados para outro local onde a aplicação está a ser executada.

Saber mais

  • Para obter informações sobre casos de utilização, compras, parceiros e fornecedores de hardware OEM, consulte a página de produto Azure Stack Hub.
  • Para obter informações sobre o roteiro e geo-disponibilidade para sistemas integrados Azure Stack Hub, consulte o livro branco: Azure Stack Hub: Uma extensão do Azure.

Passos seguintes

Modelos de ligação de implantação Azure Stack Hub