Partager via

Vue d’ensemble des modèles de référence réseau pour Azure Local

  • Article

S’applique à : Azure Local, versions 23H2 et 22H2

Important

Azure Stack HCI fait désormais partie d’Azure Local. Le changement de nom de la documentation produit est en cours. Les modifications textuelles sont terminées et les mises à jour visuelles seront bientôt finalisées. Plus d’informations

Dans cet article, découvrez comment déployer des modèles de référence réseau sur Azure Local.

Un déploiement se compose de systèmes à nœud unique ou à plusieurs nœuds (jusqu’à 16 machines par système) qui se connectent à un ou deux commutateurs TOR (Top of Rack). Ces environnements présentent les caractéristiques suivantes :

  • Au moins deux ports de carte réseau dédiés à l’intention du trafic de stockage. La seule exception à cette règle est les déploiements à nœud unique, où les cartes réseau pour le stockage ne sont pas requises si vous ne prévoyez pas d’effectuer un scale-out du système à l’avenir.

  • Un ou deux ports de carte réseau dédiés à la gestion et aux intentions de trafic de calcul.

Considérations relatives à la connectivité sans commutateur de stockage

Voici quelques considérations relatives à l’utilisation de configurations sans commutateur :

  • Les déploiements sans commutateur de stockage dans Azure Local, version 23H2 prennent uniquement en charge 1,2 ou 3 nœuds.

  • Les opérations de scale-out sur les déploiements sans commutateur de stockage à partir de Portail Azure ou ARM ne sont pas prises en charge dans les systèmes Azure Local version 23H2.

  • Aucun commutateur n’est nécessaire pour le trafic in-system (East-West) ; toutefois, un commutateur physique est requis pour le trafic en dehors du système (nord-sud).

  • Network ATC ne prend pas en charge l’autoIP du réseau de stockage sur 3 nœuds sans basculement de déploiements. La planification est requise pour les schémas d’adressage IP et de sous-réseau.

  • Les adaptateurs de stockage sont des interfaces à usage unique. La gestion, le calcul, le cluster étendu et d’autres trafics nécessitant une communication nord-sud ne peuvent pas utiliser les cartes réseau de stockage.

  • À mesure que le nombre de nœuds du système augmente au-delà de deux nœuds, le coût des cartes réseau peut dépasser le coût d’utilisation des commutateurs réseau.

  • Au-delà d’un système à trois nœuds, la complexité de la gestion des câbles augmente.

Pour plus d’informations, consultez Configuration réseau physique requise pour Azure Local.

Configuration requise du pare-feu

Azure Local nécessite une connectivité périodique à Azure. Si le pare-feu sortant de votre organisation est restreint, vous devez inclure les exigences de pare-feu pour les points de terminaison sortants et les règles et ports internes. Il existe des points de terminaison obligatoires et recommandés pour les composants principaux Azure, qui incluent la création du système, l’inscription et la facturation, Microsoft Update et le témoin cloud.

Consultez les exigences de pare-feu pour obtenir la liste complète des points de terminaison. Veillez à inclure ces URL requises dans votre liste autorisée. Les ports réseau appropriés doivent être ouverts entre toutes les machines à la fois au sein d’un site et entre des sites (pour les clusters étendus).

Le validateur de connectivité locale Azure de l’outil De vérification de l’environnement vérifie l’exigence de connectivité sortante par défaut pendant le déploiement. En outre, vous pouvez exécuter l’outil Vérificateur d’environnement autonome avant, pendant ou après le déploiement pour évaluer la connectivité sortante de votre environnement.

Une bonne pratique consiste à disposer de tous les points de terminaison pertinents dans un fichier de données accessible par l’outil de vérificateur d’environnement. Le même fichier peut également être partagé avec votre administrateur de pare-feu pour ouvrir les ports et URL nécessaires.

Pour plus d’informations, consultez la configuration requise pour le pare-feu.

Étapes suivantes