PI Services

Nous allons dans ce blog créer un cluster SOFS en utilisant  Storage Spaces Direct (S2D).

Les nœuds du cluster seront des Windows Server 2016 Nano.

Ce blog n’a pas pour vocation de configurer le cluster dans des best practices ( RDMA, réseau CSV, …), mais seulement de présenter l’intégration de S2D dans le cluster.

Pour rappel, Storage Spaces Direct permet de créer un stockage hautement disponible avec le stockage local du serveur. C’est une grande avancée dans le modèle Software Define Storage (SDS) qui va simplifier la gestion des serveurs Hyperconvergés et permettre l’utilisation de certains types de disques comme les disques SATA, les disques NVME, qu’il n’était pas possible d’utiliser précédemment dans les Storage Space Cluster sous Windows 2012.

Notre Cluster sera constitué de 4 nœuds : Nano1, Nano2, Nano3 et Nano4 avec chacun deux disques disponible.

Ajouts des serveurs Nano dans le domaine

Depuis un contrôleur de domaine, on provisionne nos 4 serveurs via la commande djoin /provision.

Exemple :

djoin.exe /provision /domain labo.local /machine NanoX /savefile C:\odjblobNanoX

Copier les fichiers respectifs générés sur les serveurs Nanos (via les partages administratifs par exemple).

Ensuite, on se connecte sur les 4 serveurs Nano depuis l’hyperviseur via PowerShell Direct (nécessite Windows 10 ou Windows Server 2016 pour cette méthode) afin de les intégrer dans le domaine via la commande djoin /requestodj.

Exemple :

djoin /requestodj /loadfile C:\odjblobNanoX /windowspath c:\windows /localos

Et on reboote les serveurs.

Désormais, les 4 serveurs Nanos sont dans le domaine.

Exemple pour Nano1

Maintenant, depuis une machine disposant des outils RSAT FailoverClusters 2K16 dans le domaine, on créé le cluster Cluster-Nano avec les nœuds Nano1, Nano2, Nano3 et Nano4.

New-Cluster -Name "Cluster-Nano" -Node Nano1, Nano2, Nano3, Nano4 –NoStorage

Depuis la MMC Failover Cluster, on peut désormais voir notre Cluster-Nano.

Activation du Storage Space Direct sur le cluster

Il faut activer au niveau du cluster la fonctionnalité Storage Space Direct via la commande suivante :

Get-cluster Cluster-Nano | Enable-ClusterStorageSpacesDirect

Les DAS de vos nœuds sont visibles dans Enclosures.

Création du Storage Pool et du Virtual Disk

Nous allons maintenant générer un Storage Pool depuis nos disques locaux des nœuds du cluster.

Spécifier un nom de Storage Pool

Sélectionner les disques devant participer au Storage Pool (ici sont affichés les 2 disques * 4 nœuds soit 8 disques)

Le Storage Pool est désormais créés.

Nous allons maintenant créer un Virtual Disk sur ce Storage Pool.

Clic droit sur le Pool et New Virtual Disk

Sélectionner votre Storage Pool précédemment créé.

Donner un nom à votre virtual Disk

Dans notre exemple, nous allons créer un miroir avec une taille de 12 GB

Cocher la case Create a volume when this wizard closes

Créer maintenant le volume. Cliquer sur Next

Sélectionner le disque disponible présent au sein du cluster

Allouer toute la capacité disponible au volume.

N’affecter pas de lettre de montage (inutile car il s’agira d’un volume CSV)

Donner un label et formater en ReFS

La ressource disque est maintenant disponible.

Ajouter ce disque en tant que CSV.

Désactiver l’intégrité sur le CSV

Set-FileIntegrity C:\ClusterStorage\Volume1 –Enable $false

Ajout du role SOFS dans le cluster

Si désormais vous souhaitez ajouter le rôle SOFS au cluster, vous aurez un message d’erreur.

Vous devez pour cela activer sur les nœuds du cluster la feature File-Services car actuellement celle-ci est désactivée.

Ajout de la feature sur les nœuds :

invoke-command -computer nano1 -scriptblock {Get-WindowsOptionalFeature -online -featureName File-Services | Enable-WindowsOptionalFeature -online}

invoke-command -computer nano2 -scriptblock {Get-WindowsOptionalFeature -online -featureName File-Services | Enable-WindowsOptionalFeature -online}

invoke-command -computer nano3 -scriptblock {Get-WindowsOptionalFeature -online -featureName File-Services | Enable-WindowsOptionalFeature -online}

invoke-command -computer nano4 -scriptblock {Get-WindowsOptionalFeature -online -featureName File-Services | Enable-WindowsOptionalFeature -online}

Désormais, vous pouvez ajouter votre rôle SOFS.

Il ne vous reste plus qu’à ajouter des partages de fichiers de type SMB Share –Applications sur le CSV reposant sur du Storage Space Direct et vous pourrez héberger vos VMs.

(Après avoir bien entendu relié le tout via du SMB 3 en exploitant le MultiChannel et le RDMA. )

Depuis la console de gestion Failover Cluster Manager, il est facile de sélectionner les réseau devant être utilisé par le Live Migration.

Allez sur Network ==> clique droit Live Migration Settings

Et il ne vous reste plus qu’a sélectionner les interfaces réseaux souhaitées.

Maintenant pour effectuer la même opération en Powershell, veuillez taper:

Get-ClusterResourceType -Name "Virtual Machine" | Set-ClusterParameter -Name MigrationExcludeNetworks -Value ([String]::Join(";",(Get-ClusterNetwork | Where-Object {$_.Name -notmatch "LM" -and $_.Name -notmatch "VN -"}).ID))   

Dans le filtre de la commande:

Where-Object {$_.Name -notmatch "XXX" -and $_.Name -notmatch "XXX"}).ID))

Veuiller taper comme valeurs pour les XXX une partie de la chaine de caractère du nom matchant vos interfaces réseaux afin de les identifier.

Vous souhaitez modifier les propriétés générale de la ressource cluster DHCP server en Powershell.

Récupérer dans 3 variables les Paths que vous voulez définir pour :

• Database path
• Audit file path
• Backup path

$DatabasePath="j:\dhcp\db"
$AuditFilePath="j:\dhcp\logs"
$BackupPath="j:\dhcp\backup"

Récupérer maintenant votre ressource de type DHCP Service
$RessDHCP=get-ClusterResource "DHCP Server"

Nous allons maintenant manipuler des instances basées sur Microsoft.FailoverClusters.PowerShell.ClusterParameter qui va nous permettre de manipuler nos propriétés.

Modification du Database Path
$param1 = New-Object Microsoft.FailoverClusters.PowerShell.ClusterParameter $RessDHCP,DatabasePath,$DatabasePath

$param1 | Set-ClusterParameter

Modification de l'Audit File Path
$param2 = New-Object Microsoft.FailoverClusters.PowerShell.ClusterParameter $RessDHCP,LogFilePath,$AuditFilePath

$param2 | Set-ClusterParameter

Modification du Backup path
$param3 = New-Object Microsoft.FailoverClusters.PowerShell.ClusterParameter $RessDHCP,BackupPath,$BackupPath

$param3 | Set-ClusterParameter

Les propriétés sont maintenant définis.

Vous souhaitez créer en ligne de commande un groupe de ressource Cluster.

Pour cela, il faut utiliser la ligne de commande suivante :

([wmiclass]"root\MSCluster:MSCluster_ResourceGroup").CreateGroup(“NomDuGroupe”, XXX)

Ou XXX représente l’identifiant du groupe de ressource que vous voulez créer.

Par exemple : pour créer un groupe de ressource Hyper-V réplica Broker, vous devez saisir l’ID 115 soit :

([wmiclass]"root\MSCluster:MSCluster_ResourceGroup").CreateGroup(“NomDuGroupe”, 115)

Maintenant, pour créer un groupe de ressource DHCP Cluster, l’identifiant correspondant est le 102 soit :

([wmiclass]"root\MSCluster:MSCluster_ResourceGroup").CreateGroup(“NomDuGroupe”, 102)

Ci-dessous, une capture d’écran qui vous donnera l’ID associé à un type de groupe de ressource Cluster.

Afin d’effectuer une montée de version dans des conditions optimales, l’un des pré-requis de base consiste à installer le Deployment Scanner de la version désirée sur le ou les serveurs Symantec Enterprise Vault. Cet outil permet de vérifier et de valider le positionnement des socles de base permettant d’effectuer cet Upgrade.

Lors d’une montée de version vers la v9, un effet indésirable peut être constaté. Le Deployment Scanner affiche un problème de compatibilité inter version, depuis le nœud actif comme le nœud passif, rendant impossible cette mise à jour. En effet, le dernière version listée semble être la 7.5.x alors qu’elle devrait être en 8.0.x, et du coup le passage en version 9 est impossible car il y a un delta de 2 versions. Afin de vérifier ces informations, il suffit d’aller en base de registre “\HKLM\Software\KVS\Enterprise Vault\Install” :

Afin de contrer ce bug, le passage en version 9 devra comporter une étape de plus, et en l’occurrence, l’application d’un service pack supplémentaire afin d’effectuer une capture de la base de registre une fois cette étape réalisée. Du coup, les process pour le passage en version 9 se complique.

Nœud Actif :

1. Installation du Deployment Scanner de la version 8.0.”X+1”
2. Lancement du Deployment Scanner pour vérification du positionnement des pré-requis
3. Arrêt des services EV depuis la console Cluster MSCS (pour rappel, l’arrêt du service Admin stoppe tous les autres services)
4. Lancement du SETUP.EXE de la version 8.0.”X+1” et installation
5. Vérification de la version dans la base de registre (Cf. clé énoncée précédemment), puis EXPORTde la clé : “\HKLM\Software\KVS\Enterprise Vault”

Nœud Passif :

1. Installation du Deployment Scanner de la version 8.0.”X+1”
2. Lancement du Deployment Scanner pour vérification du positionnement des pré-requis
3. Lancement du SETUP.EXE de la version 8.0.”X+1” et installation
4. Vérification de la version dans la base de registre (Cf. clé énoncée précédemment), puis EXPORTde la clé : “\HKLM\Software\KVS\Enterprise Vault” en cas de besoin

Nœud Actif :

• Depuis la console Cluster MSCS, démarrer les services “Admin” et “Directory” et attendre l’arrivée des Event dans le journal d’évènement Enterprise Vault (Cf. procédures d’installation standards)
• Nouvelle vérification de la version dans la base de registre, et si confirmation d’un effet rétro-actif, injecter les clés précédemment sauvegardées (un double-clic sur le fichier .REG repositionne les clés aux bonnes valeurs)
• Démarrer les services restant en suivant les procédures standards

Nœud Passif :

• Depuis la console Cluster MSCS, effectuer une bascule de toutes les ressources et vérifier en base de registre le bon positionnement des valeurs précédemment sauvegardées. Normalement, les valeurs positionnées suite à la mise à jour sont toujours présentes car elles sont embarquées par les services Enterprise Vault concernés.

Une fois ces manipulations effectuées, le passage en version 9 devient possible. Il suffira alors de suite les procédures standards.

Références: http://www.symantec.com/business/support/index?page=content&id=TECH70138&actp=search&viewlocale=en_US&searchid=1292493096299

N'hésitez pas à laisser un commentaire si ce tips vous a été utile ou bien si vous avez des éléments à ajouter !…