Cluster Hyper-V et Datacore
Modérateurs : Modérateurs, Modérateurs_Divers
-
- N00b
- Messages : 1
- Inscription : mer. 04 oct. 2017, 7:22
Cluster Hyper-V et Datacore
Bonjour,
J'ai un soucis avec un nouveau Cluster Hyper-V et Datacore.
C'est pas le premier que je monte, mais là cela me dépasse.
J'ai 2x Dell R730XD, avec plusieurs RAID SSD, SAS et SATA.
L'objectif est de présenter un stockage géré par Datacore aux 2 Hyper-V en iSCSI.
Mon soucis provient lors de l'ajout des 2 noeuds dans le Cluster de Basculement.
Pour vérifier ce qu'il se passe, j'ai commencé par en ajouter un. Aucun soucis !!
Pour l'ajout du second cela coince.... J'ai 1 erreur qui bloque l'ajout, quand je passe les tests.
Soucis de Réseau, il me parle d'un test en UDP sur le port 3343 ....
Les interfaces réseau SRV-DTC01.cluster.gfym.local - vEthernet (VMs) et srv-dtc02.cluster.gfym.local - vEthernet (VMs) sont sur le même réseau de cluster, or l’adresse 192.168.16.2 n’est pas accessible à partir de 192.168.16.1 en utilisant le protocole UDP sur le port 3343.
Les interfaces réseau SRV-DTC01.cluster.gfym.local - NIC-INT-P4-ISCSI-1 et srv-dtc02.cluster.gfym.local - NIC-ADD-ISCSI-P2 sont sur le même réseau de cluster, or l’adresse 172.16.0.12 n’est pas accessible à partir de 172.16.0.1 en utilisant le protocole UDP sur le port 3343.
Les interfaces réseau srv-dtc02.cluster.gfym.local - vEthernet (VMs) et SRV-DTC01.cluster.gfym.local - vEthernet (VMs) sont sur le même réseau de cluster, or l’adresse 192.168.16.1 n’est pas accessible à partir de 192.168.16.2 en utilisant le protocole UDP sur le port 3343.
Les interfaces réseau srv-dtc02.cluster.gfym.local - NIC-ADD-ISCSI-P2 et SRV-DTC01.cluster.gfym.local - NIC-INT-P4-ISCSI-1 sont sur le même réseau de cluster, or l’adresse 172.16.0.1 n’est pas accessible à partir de 172.16.0.12 en utilisant le protocole UDP sur le port 3343.
Le nœud srv-dtc02.cluster.gfym.local et le nœud SRV-DTC01.cluster.gfym.local sont connectés par un ou plusieurs chemins de communication qui utilisent des réseaux désactivés. Ces chemins ne seront pas utilisés pour la communication de cluster et seront ignorés. La raison en est que les interfaces sur ces réseaux sont connectées à une cible iSCSI. Songez à ajouter des réseaux au cluster ou modifiez le rôle d’un ou de plusieurs réseaux de cluster après la création du cluster pour garantir la redondance des communications de cluster.
Le chemin de communication entre l’interface réseau SRV-DTC01.cluster.gfym.local - NIC-ADD-10G-P2 et l’interface réseau srv-dtc02.cluster.gfym.local - NIC-ADD-10G-P2 se trouve sur un réseau désactivé.
Le chemin de communication entre l’interface réseau SRV-DTC01.cluster.gfym.local - NIC-ADD-10G-P1 et l’interface réseau srv-dtc02.cluster.gfym.local - NIC-ADD-10G-P1 se trouve sur un réseau désactivé.
Après plusieurs tests, voici la configuration.
J'ai configuré comme suis :
Serveur 1
4 Cartes 1G en Teaming et présentée à Hyper-V = vEthernet (VMs) en 192.168.16.1
1 Carte 10G pour le Miroir Datacore = NIC-ADD-10G-P1 en 10.0.1.1
1 Carte 10G pour le Miroir Datacore = NIC-ADD-10G-P2 en 10.0.2.1
1 Carte 1G pour le iSCSI = NIC-INT-P4-ISCSI-1 en 172.16.0.1
1 Carte 1G pour le iSCSI = NIC-ADD-ISCSI-P2 en 172.16.0.11
Serveur 1
4 Cartes 1G en Teaming et présentée à Hyper-V = vEthernet (VMs) en 192.168.16.2
1 Carte 10G pour le Miroir Datacore = NIC-ADD-10G-P1 en 10.0.1.2
1 Carte 10G pour le Miroir Datacore = NIC-ADD-10G-P2 en 10.0.2.2
1 Carte 1G pour le iSCSI = NIC-INT-P4-ISCSI-1 en 172.16.0.2
1 Carte 1G pour le iSCSI = NIC-ADD-ISCSI-P2 en 172.16.0.12
Au départ, les iSCSI-P2 étaient sur un autre réseau en 172.31.0.x/24
Les cartes 10G sont interconnectées par un câble directement.
Les cartes iSCSI sont sur le même switch que la prod, mais dans un VLAN, ou j'ai mis un PVID sur les ports.
Tout répond au ping, je ne capte pas.
Dans le cluster, seul le réseau 192.168.16.0/24 est en mode "Cluster et Client", les autres sont désactivés.
J'ai un soucis avec un nouveau Cluster Hyper-V et Datacore.
C'est pas le premier que je monte, mais là cela me dépasse.
J'ai 2x Dell R730XD, avec plusieurs RAID SSD, SAS et SATA.
L'objectif est de présenter un stockage géré par Datacore aux 2 Hyper-V en iSCSI.
Mon soucis provient lors de l'ajout des 2 noeuds dans le Cluster de Basculement.
Pour vérifier ce qu'il se passe, j'ai commencé par en ajouter un. Aucun soucis !!
Pour l'ajout du second cela coince.... J'ai 1 erreur qui bloque l'ajout, quand je passe les tests.
Soucis de Réseau, il me parle d'un test en UDP sur le port 3343 ....
Les interfaces réseau SRV-DTC01.cluster.gfym.local - vEthernet (VMs) et srv-dtc02.cluster.gfym.local - vEthernet (VMs) sont sur le même réseau de cluster, or l’adresse 192.168.16.2 n’est pas accessible à partir de 192.168.16.1 en utilisant le protocole UDP sur le port 3343.
Les interfaces réseau SRV-DTC01.cluster.gfym.local - NIC-INT-P4-ISCSI-1 et srv-dtc02.cluster.gfym.local - NIC-ADD-ISCSI-P2 sont sur le même réseau de cluster, or l’adresse 172.16.0.12 n’est pas accessible à partir de 172.16.0.1 en utilisant le protocole UDP sur le port 3343.
Les interfaces réseau srv-dtc02.cluster.gfym.local - vEthernet (VMs) et SRV-DTC01.cluster.gfym.local - vEthernet (VMs) sont sur le même réseau de cluster, or l’adresse 192.168.16.1 n’est pas accessible à partir de 192.168.16.2 en utilisant le protocole UDP sur le port 3343.
Les interfaces réseau srv-dtc02.cluster.gfym.local - NIC-ADD-ISCSI-P2 et SRV-DTC01.cluster.gfym.local - NIC-INT-P4-ISCSI-1 sont sur le même réseau de cluster, or l’adresse 172.16.0.1 n’est pas accessible à partir de 172.16.0.12 en utilisant le protocole UDP sur le port 3343.
Le nœud srv-dtc02.cluster.gfym.local et le nœud SRV-DTC01.cluster.gfym.local sont connectés par un ou plusieurs chemins de communication qui utilisent des réseaux désactivés. Ces chemins ne seront pas utilisés pour la communication de cluster et seront ignorés. La raison en est que les interfaces sur ces réseaux sont connectées à une cible iSCSI. Songez à ajouter des réseaux au cluster ou modifiez le rôle d’un ou de plusieurs réseaux de cluster après la création du cluster pour garantir la redondance des communications de cluster.
Le chemin de communication entre l’interface réseau SRV-DTC01.cluster.gfym.local - NIC-ADD-10G-P2 et l’interface réseau srv-dtc02.cluster.gfym.local - NIC-ADD-10G-P2 se trouve sur un réseau désactivé.
Le chemin de communication entre l’interface réseau SRV-DTC01.cluster.gfym.local - NIC-ADD-10G-P1 et l’interface réseau srv-dtc02.cluster.gfym.local - NIC-ADD-10G-P1 se trouve sur un réseau désactivé.
Après plusieurs tests, voici la configuration.
J'ai configuré comme suis :
Serveur 1
4 Cartes 1G en Teaming et présentée à Hyper-V = vEthernet (VMs) en 192.168.16.1
1 Carte 10G pour le Miroir Datacore = NIC-ADD-10G-P1 en 10.0.1.1
1 Carte 10G pour le Miroir Datacore = NIC-ADD-10G-P2 en 10.0.2.1
1 Carte 1G pour le iSCSI = NIC-INT-P4-ISCSI-1 en 172.16.0.1
1 Carte 1G pour le iSCSI = NIC-ADD-ISCSI-P2 en 172.16.0.11
Serveur 1
4 Cartes 1G en Teaming et présentée à Hyper-V = vEthernet (VMs) en 192.168.16.2
1 Carte 10G pour le Miroir Datacore = NIC-ADD-10G-P1 en 10.0.1.2
1 Carte 10G pour le Miroir Datacore = NIC-ADD-10G-P2 en 10.0.2.2
1 Carte 1G pour le iSCSI = NIC-INT-P4-ISCSI-1 en 172.16.0.2
1 Carte 1G pour le iSCSI = NIC-ADD-ISCSI-P2 en 172.16.0.12
Au départ, les iSCSI-P2 étaient sur un autre réseau en 172.31.0.x/24
Les cartes 10G sont interconnectées par un câble directement.
Les cartes iSCSI sont sur le même switch que la prod, mais dans un VLAN, ou j'ai mis un PVID sur les ports.
Tout répond au ping, je ne capte pas.
Dans le cluster, seul le réseau 192.168.16.0/24 est en mode "Cluster et Client", les autres sont désactivés.