Comportement SMP et interaction

Article
11/22/2024

API d’infrastructure de gestion et de méthodes intrinsèques

Les développeurs SMP (Storage Management Provider) travaillent avec :

Méthodes intrinsèques générées par Convert-MofToProvider.exe.
API d’infrastructure de gestion (MI) du fichier mi.h pour fournir l’implémentation de leur SMP.

Les puces suivantes notent quelques méthodes intrinsèques et MI clés.

EnumerateInstances et GetInstance

EnumerateInstances est appelée lorsqu’il existe une requête pour les instances d’une classe particulière. Par exemple : l’applet de commande PowerShell Get-Object<> est mappée à la méthode EnumerateInstances de l’objet WMI correspondant. Cette méthode doit retourner toutes les instances de la classe via <la méthode Object>_Post. Étant donné que WMI appelle fréquemment EnumerateInstances, il doit s’exécuter rapidement. Pour ce faire, utilisez une bonne gestion du cache.

GetInstance est appelé lorsqu’une instance spécifique d’une classe est nécessaire, par exemple (mais pas limitée à) :
- Lorsque l’infrastructure WMI appelle n’importe quelle méthode de cette classe
- Lorsqu’une application WMI appelle directement cette méthode
- Lorsqu’une instance de la classe est demandée via des classes d’association
La méthode GetInstance ne doit retourner que l’objet spécifié via <la méthode Object>_Post. L’identificateur de l’instance interrogée, c’est-à-dire la « clé » telle que définie dans MOF, qui est généralement l’ObjectId, est récupérée via le paramètre InstanceName. Cette méthode est appelée fréquemment par WMI et doit se terminer rapidement.

EnumerateInstances et GetInstance sont obligatoires pour les classes régulières telles que StorageProvider, StorageSubsystem, PhysicalDisk, etc.

Pour les classes Association, EnumerateInstances, AssociatorInstances et ReferenceInstances sont obligatoires, tandis que GetInstance n’est pas.
<Objet>_Post et MI_PostResult

Pour comprendre la différence entre la méthode <d’API MI, Object>_Post et MI_PostResult :
- <Considérez Object>_Post comme renvoyant un pointeur vers un paramètre de sortie.
- Considérez MI_PostResult comme une valeur de retour de fonction qui indique l’état d’exécution de la fonction.
Vous ne devez appeler MI_PostResult qu’une seule fois par méthode WMI « context », qui se trouve dans les paramètres d’entrée de chaque méthode WMI. « Context » est un pointeur vers les rappels WMI. L’appel de MI_PostResult détruit ce pointeur. Par conséquent, une méthode WMI ne doit jamais être appelée dans le corps d’une autre méthode WMI.

<L’objet>_Post, d’autre part, peut être appelé plusieurs fois par contexte de méthode WMI. Cette méthode est généralement utilisée dans EnumerateInstances pour retourner plusieurs objets.
Set,<propriété> et ModifyInstance

La méthode intrinsèque ModifyInstance n’est pas prise en charge par le biais de l’API gestion du stockage Windows. Pour modifier les propriétés d’un objet, la propriété Set<> de la méthode extrinsique est utilisée.

Pour plus d’informations sur les méthodes intrinsèques et les API MI, reportez-vous aux exemples d’API MI du Kit de développement logiciel (SDK) Windows.

Identification d’objet

Les interfaces SMP utilisent les deux groupes de propriétés suivants pour l’identification d’objet :

Pour le script et la programmation : ObjectId et UniqueId

ObjectId est un identificateur opaque créé et géré pour l’utilisation des SPM et de leurs clients pour suivre l’instance d’objets. Il s’agit d’une propriété obligatoire qui doit être globalement unique. Autrement dit, aucun objet ne doit avoir le même ObjectId, même s’ils sont gérés par des SPM distincts ou se trouvent sur des sous-systèmes de stockage différents.

Si un objet est visible par le biais de deux chemins d’accès différents (par exemple : il existe deux SMPs distincts qui pointent vers le même sous-système de stockage), le même objet peut apparaître avec deux ObjectIds différents. Pour déterminer si deux instances d’objet sont le même objet, utilisez la propriété UniqueId.

UniqueId est une propriété obligatoire utilisée pour identifier de manière unique une instance d’une classe dans une étendue globale. Cette valeur doit être la même entre deux instances de SPM exécutées sur différents serveurs d’administration. Contrairement à ObjectId, UniqueId doit être une valeur que le sous-système de stockage conserve plutôt que le processus du fournisseur de gestion du stockage.

UniqueId peut être n’importe quelle valeur opaque sauf indication contraire (par exemple : MSFT_VirtualDisk).
Pour l’affichage : FriendlyName et Name

Les utilisateurs finaux utilisent ces deux propriétés pour identifier un objet. FriendlyName est une chaîne conviviale définie par les utilisateurs finaux, si le SMP prend en charge une telle opération. FriendlyName n’a pas besoin d’être unique. Deux objets d’un sous-système de stockage unique peuvent partager le même FriendlyName, bien que cette pratique soit déconseillée.

Le SMP définit la propriété Name et les utilisateurs finaux ne peuvent pas le modifier. Le SMP fournit des informations supplémentaires dans cette propriété pour aider les utilisateurs finaux à identifier un objet. Ces informations peuvent couvrir les aspects techniques de l’objet. Par exemple, le nom d’un sous-système de stockage peut être l’adresse IP ou WWN du sous-système. Le nom est généralement unique dans certaines étendues. Par exemple, le nom d’un pool de stockage doit être unique dans le sous-système de stockage propriétaire.

Gestion des erreurs

Il existe trois types d’erreurs dans les interfaces SMP : les codes de retour de l’API de gestion du stockage Windows (API SM), les « erreurs réversibles » et les « erreurs matérielles ».

Les codes de retour de l’API SM font référence aux codes d’erreur répertoriés comme valeurs de retour pour chacune des méthodes extrinsiques SMP. Par exemple, « 5 » représente « Paramètre non valide ». Ces codes d’erreur sont retournés via le paramètre de sortie MIReturn défini dans la structure de méthode générée par Convert-MofToProvider.exe. La valeur de MIReturn peut être définie via <Object> _<Method>_Set_MIReturn définie dans le fichier d’en-tête de l’objet correspondant.

Les méthodes extrinsiques doivent toujours utiliser par défaut les codes d’erreur de l’API SM lorsque cela est possible. Si des informations supplémentaires sont nécessaires, les fournisseurs de services de gestion cloud peuvent utiliser MSFT_ExtendedStatus classe pour fournir des informations d’état supplémentaires sur l’appel d’une méthode extrinsique. Cette approche est préférable à l’utilisation d’erreurs réversibles pour les méthodes extrinsiques.

Les erreurs réversibles font référence aux messages d’erreur retournés via la classe MSFT_SoftError. Ces erreurs sont conçues pour les méthodes intrinsèques (EnumerateInstances, GetInstance et etc.) où il n’est pas possible de retourner des codes d’erreur d’API SM. Pour retourner des erreurs réversibles, les instances des classes d’erreurs réversibles dérivées de MSFT_SoftError doivent être construites et retournées via le paramètre « MI_Instance error » dans MI_WriteCimError méthode définie dans mi.h. Par exemple, pour indiquer que « les informations d’identification correctes sont nécessaires » lors de la connexion au tableau de stockage, une instance de « MSFT_SoftError_NotAuthenticated » peut être retournée pendant les appels d’Énumérations sur les objets StorageSubsystem. Pour les erreurs réversibles, un résultat de MI_RESULT_OK doit toujours être publié via MI_PostResult.

Les erreurs difficiles font référence aux erreurs définies dans MI_Result structure à partir du fichier mi.h . Les API MI retournent ces erreurs. SMP doit éviter de faire face directement à ces erreurs aux applications de gestion du stockage, sauf si absolument nécessaire. Par exemple, pour les « paramètres non valides », les SPM doivent utiliser MIReturn pour exposer le code d’erreur de l’API SM « 5 » – « Paramètre non valide » au lieu de compter sur l’application de gestion du stockage pour consommer MI_RESULT_INVALID_PARAMETER.

Primordial Pool

Un pool primordial, également appelé pool « stockage disponible », est l’endroit où la capacité de stockage est dessinée et retournée dans la création et la suppression de pools de stockage concrets. Les pools primordial ne peuvent pas être créés, supprimés ou modifiés.

Les SPM doivent fournir au moins un pool primordial. Lorsqu’un disque physique est ajouté à un pool de stockage concret, le disque physique doit toujours être considéré comme faisant partie du pool primordial.

Rapports de taille

Il existe deux cas spéciaux pour discuter des différents champs de taille des objets du pool de stockage : la capacité des lecteurs de rechange à chaud et la capacité des lecteurs défectueux.

Une fois qu’un lecteur est nommé en tant que disque de rechange à chaud, sa capacité doit être incluse dans l’allocationSize du pool primordial correspondant. Toutefois, la capacité du lecteur ne doit pas être incluse dans la taille d’un pool de béton, même si le tableau de stockage prend en charge l’appel d’un lecteur de rechange chaud à un pool de béton spécifique. Une fois qu’un disque de rechange à chaud est consacré à un pool de béton particulier, la capacité du lecteur ne doit pas être incluse dans l’allocationSize du pool de béton jusqu’à ce qu’elle remplace réellement un lecteur utilisé. Lorsqu’il est ajouté à un pool concret, CanPooled doit avoir la valeur FALSE pour l’objet Disque physique de ce lecteur de rechange à chaud. Une association doit être créée entre cet objet Disque physique et l’objet pool de stockage du pool de stockage.

La capacité des lecteurs avec HealthStatus « Non sain » ne doit pas être incluse dans des champs de taille provenant d’un pool primordial ou d’un pool de béton.

Associations

L’API SM inclut des classes d’association qui définissent des relations entre les objets de stockage. Avec ces classes d’association, il est facile de parcourir la hiérarchie d’objets de stockage pour obtenir des objets connexes pour un objet donné. Pour le module PowerShell de stockage, la piping d’applet de commande est obtenue via des classes d’association. Par exemple, en fonction d’un objet Disque virtuel, les utilisateurs peuvent obtenir le pool de stockage propriétaire de l’objet Disque virtuel via l’applet de commande suivante :

    PS> Get-VirtualDisk –FriendlyName MyVirtualDisk | Get-StoragePool

Le reste de cette section illustre l’implémentation des classes d’association. Les méthodes des notes sont générées par Convert-MofToProvider.exe pour chaque classe d’association. Les notes utilisent XToY comme exemple de classe d’association ; le pseudo-code utilise StoragePoolToVirtualDisk comme exemple.

EnumerateInstances et GetInstance

      - XToY\_EnumerateInstances returns association objects (XToY objects) for ALL X objects
    
    <!-- end list -->
    
        void MI_CALL SAMPLE_StoragePoolToVirtualDisk_EnumerateInstances( ... )
        {
            ...
        
        /** This method should return association objects for ALL Storage Pools. **/
        
            // for each storage pool
        
                // for each virtual disk that's associated with this storage pool
        
                    // create the StoragePoolToVirtualDisk association object
                    // set the storage pool object and virtual disk object to this association object
                    // post the association object
                
                // end for
        
            // end for
        
            ...
        }

AssociatorInstances

      - AssociatorInstances method returns regular objects instead of association objects
      - XToY\_AssociatorInstancesX should return all associated Y object(s) for the X specified
      - XToY\_AssociatorInstancesY should return all associated X object(s) for the Y specified
    
    <!-- end list -->
    
        void MI_CALL SAMPLE_StoragePoolToVirtualDisk_AssociatorInstancesStoragePool(...)
        {
            ...
        
        /** This method should return VIRTUAL DISK object(s) for the 
        STORAGE POOL specified. **/
        
            // for each virtual disk that's associated with this storage pool
        
                // create the virtual disk object
                // post the virtual disk object
                
            // end for
        
            ...
        }
        
        void MI_CALL SAMPLE_StoragePoolToVirtualDisk_AssociatorInstancesVirtualDisk(...)
        {
            ...
        
        /** This method should return STORAGE POOL object(s) for the 
        VIRTUAL DISK specified. **/
        
            // for each storage pool that's associated with this virtual disk
        
                // create the storage pool object
                // post the storage pool object
                
            // end for
        
            ...
        }

ReferenceInstances

      - ReferenceInstances is similar to AssociatorInstances except that these methods return association (XToY) objects instead of regular objects
      - XToY\_ReferenceInstancesX should return XToY object(s) for X specified
      - XToY\_ReferenceInstancesY should return YToX object(s) for Y specified
    
    <!-- end list -->
    
        void MI_CALL SAMPLE_StoragePoolToVirtualDisk_ReferenceInstancesStoragePool(...)
        {
            ...
        
        /** This method should return StoragePoolToVirtualDisk 
        ASSOCIATION object(s) for the STORAGE POOL specified. **/
        
            // for each virtual disk that's associated with this storage pool
        
                // create the StoragePoolToVirtualDisk association object
                // set the storage pool and virtual disk to this association object
                // post the association object
                
            // end for
        
        
            ...
        }
        
        void MI_CALL SAMPLE_StoragePoolToVirtualDisk_ReferenceInstancesVirtualDisk(...)
        {
            ...
        
        /** This method should return StoragePoolToVirtualDisk 
        ASSOCIATION object(s) for the VIRTUAL DISK specified. **/
        
            // for each storage pool that's associated with this virtual disk
        
                // create the StoragePoolToVirtualDisk association object
                // set the storage pool and virtual disk to this association object
                // post the association object
                
            // end for
        
            ...
        }

Gestion du cache

Lorsque le SMP est chargé, il doit initialiser un cache d’objets de stockage. Cette initialisation garantit un temps de réponse rapide lors de la maintenance des appels d’API en tant qu’objets pouvant être récupérés directement à partir du cache de SMP. Ce cache doit être synchronisé avec les modifications d’objet in-band et les modifications d’objet hors bande.

Les modifications apportées aux objets en bande incluent ces modifications apportées via l’instance SMP actuelle. Par exemple, si un disque virtuel est créé via l’instance SMP actuelle :

Un nouvel objet Virtual Disk doit être ajouté au cache.
Les objets associés tels que le pool de stockage propriétaire et les objets port cible associés doivent également être mis à jour.

Les modifications hors bande incluent les modifications apportées par le biais d’outils propriétaires du fournisseur et d’hébergement de PME sur d’autres ordinateurs. Par exemple, si un disque virtuel est créé via des outils propriétaires du fournisseur, un événement doit être envoyé du sous-système de stockage aux SMP(s) pour déclencher une mise à jour du cache.

SMP doit également mettre à jour le cache lorsque la méthode Discover à partir de la classe fournisseur de stockage est appelée. L’application de gestion du stockage appelle cette méthode pour réinitialiser et reconstruire le cache sur un événement tel que le redémarrage du service ou le redémarrage du système.

S’il n’est pas possible pour le SMP d’initialiser l’intégralité du cache au démarrage (en raison d’un trop grand nombre d’objets ou parce qu’il ne peut pas être effectué rapidement), seuls les objets fournisseur de stockage et sous-système de stockage doivent être chargés dans le cache. Les applications examinent la propriété CurrentCacheLevel sur l’objet sous-système de stockage pour savoir comment le cache a été rempli. L’utilisateur final ou l’application chargent explicitement le reste du cache via la méthode Discover.

Opérations asynchrones

Toute opération qui prend plus de 30 secondes pour se terminer doit retourner un objet De travail de stockage. Les méthodes qui contiennent un paramètre de sortie CreatedStorageJob sont probablement de ce type d’opération. Les SPM doivent implémenter toutes ces méthodes en tant qu’opérations asynchrones et retourner des objets de travail de stockage pour eux. Un objet De travail de stockage doit être retourné à l’appelant dans les 30 secondes ; sinon, l’appelant peut expirer s’il attend trop longtemps et n’a toujours pas reçu l’objet Tâche de stockage.

Les applications (ou « client WMI ») ont la possibilité de spécifier si une méthode doit être « RunAsJob » ou non. L’API SM que les applications utilisent contient ce paramètre RunAsJob booléen supplémentaire et le paramètre de sortie CreatedStorageJob. Pendant ce temps, les méthodes correspondantes dans les interfaces SMP ont uniquement le paramètre CreatedStorageJob. Toutefois, quelle que soit la valeur de « RunAsJob », les SPM doivent toujours retourner des objets de travail de stockage pour ces méthodes.

Les scénarios suivants illustrent la séquence d’appels d’opérations asynchrones. CreateVirtualDisk est utilisé comme exemple :

Si « RunAsJob » a la valeur TRUE

Lorsque CreateVirtualDisk est appelé, les SPM doivent effectuer l’initialisation de la méthode, démarrer un travail dans le sous-système de stockage et retourner un objet De travail de stockage à l’appelant dans les 30 secondes. Toutefois, le sous-système de stockage peut prendre n’importe quel temps pour terminer l’opération. L’appelant interroge l’état du travail pendant cette période.

Les threads de travail doivent être utilisés pour exécuter les travaux. À des fins d’efficacité, les SPM peuvent mettre à jour les attributs liés à l’état du travail (par exemple, PercentComplete) uniquement lorsque l’appelant interroge l’état de ce travail.
Si « RunAsJob » a la valeur FALSE

L’appelant est bloqué sur la méthode CreateVirtualDisk jusqu’à ce que la méthode retourne. L’API SM effectue automatiquement le blocage et l’interrogation lui-même. Ce type d’appelant est généralement un client non interactif par l’utilisateur (par exemple, un outil de script) qui préfère le mécanisme de blocage.

Étant donné que la seule façon d’obtenir des informations sur un objet nouvellement créé est l’association entre cet objet et l’objet de travail de stockage correspondant, les SPM doivent conserver un objet de travail de stockage pendant au moins 24 heures avant de le supprimer du cache. Pour les autres opérations qui ne retournent pas d’objet nouvellement créé (par exemple, une opération DeleteObject), une association n’est pas nécessaire et l’objet Tâche de stockage doit uniquement rester actif pendant 15 minutes.

Pour les redémarrages inattendus du système sur les console de gestion, les fournisseurs de services de gestion de base doivent conserver un cache d’objets StorageJob à un emplacement physique, par exemple dans le tableau de stockage, et recharger le cache lors du redémarrage du système.

Contrôle du temps de vie du fournisseur

Un SMP peut être implémenté en tant que fournisseur couplé ou découplé. Pour connaître la différence entre ces deux types de fournisseurs, reportez-vous à la documentation MSDN de WMI.

Un fournisseur découplé est chargé et hébergé dans un processus spécifique à un fournisseur. Ce processus est généralement un service toujours en cours d’exécution.

Le démarrage d’un fournisseur peut prendre du temps, car il implique de recharger le cache. Si votre démarrage SMP nécessite plus d’une seconde pour charger, nous vous recommandons d’implémenter un fournisseur découplé pour gérer les objets de stockage via un cache persistant. Cette approche permet d’augmenter les performances globales et la réactivité des applications qui utilisent l’API Windows SM pour gérer votre SMP.

L’exemple DecoupledHost du Kit de développement logiciel (SDK) Windows fournit plus de détails sur les fournisseurs découplés.

Indications

Les développeurs d’applications souhaitent souvent savoir quand l’état d’un objet change à mesure qu’il change. Ils peuvent le faire en s’abonnant aux indications WMI. Les indications sont un type différent de classe ; Ils sont exposés de manière asynchrone, parfois hors bande de toute opération de gestion et ne sont pas conservés. Au lieu d’implémenter les méthodes intrinsèques familières (autrement dit, EnumerateInstances / GetInstance), il existe de nouvelles méthodes qui doivent être prises en charge.

Il existe quatre types d’indications :

Arrivée : cette indication est utilisée lorsqu’une instance d’appareil ou d’objet est ajoutée au sous-système. Par exemple : ajout d’un nouveau disque physique au sous-système ou création d’un disque virtuel.
Départ : cette indication est utilisée lorsqu’une instance d’appareil ou d’objet est supprimée du sous-système. Par exemple : suppression d’un disque physique du sous-système ou suppression d’un pool de stockage.
Modifier : cette indication est utilisée lorsqu’une propriété importante change sur un objet existant. Au minimum, les modifications HealthStatus et OperationalStatus doivent déclencher une indication Modify. L’indication d’une modification de toute autre propriété liée à l’état d’exploitation d’un objet est fortement encouragée.
Alerte : cette indication est utilisée pour alerter l’application à un problème potentiel. Actuellement, la seule alerte définie consiste à avertir lorsqu’un seuil d’approvisionnement dynamique est atteint.

Pour implémenter des indications, il existe deux nouvelles méthodes intrinsèques qui doivent être implémentées pour chaque classe d’indication :

EnableIndication : une demande d’abonnement à la classe d’indication a été effectuée. L’indicationContext doit être enregistrée afin qu’elle soit disponible pour publier une indication ultérieurement.
DisableIndication : il n’y a plus d’abonnés à la classe d’indication. Le nettoyage doit se produire et aucune autre indication de cette classe ne doit être publiée. indicationContext est détruit pour l’instant.

Déploiement

Les SPM sont installés sur les « serveurs d’administration » sélectionnés. Ces serveurs peuvent être cluster pour fournir une redondance. D’autres serveurs accèdent au stockage alloué à eux via iSCSI ou Fibre Channel. Toutes ces machines peuvent être gérées par des serveurs qui exécutent l’interface utilisateur du serveur de fichiers à partir de Gestionnaire de serveur.

Toutefois, les fournisseurs de stockage sont invités à choisir le modèle de déploiement le mieux adapté à leurs besoins.

Modèle de sécurité

L’interface SMP prend en charge le modèle d’authentification unique (SSO) à l’aide des informations d’identification de sécurité Windows.

Dans le modèle d’authentification unique, un utilisateur se connecte à un « ordinateur de gestion » avec ses informations d’identification Windows une fois et obtient automatiquement l’accès à toutes les ressources de stockage auxquelles il dispose d’une autorisation d’accès. Il n’est pas nécessaire d’avoir plus d’informations d’identification pour la connexion au sous-système de stockage.

L’interface permet également aux administrateurs de stockage de gérer le contrôle d’accès sur les ressources de stockage individuelles. Pour chaque ressource de stockage, les administrateurs de stockage peuvent accorder différents droits d’accès à n’importe quel utilisateur Windows via les méthodes GetSecurityDescriptor et SetSecurityDescriptor. Par conséquent, les SPM, contrairement au modèle VDS, peuvent désormais recevoir des demandes de n’importe quel type de compte d’utilisateur.

Pour implémenter le modèle d’authentification unique, un SMP doit authentifier les clients Windows auprès du sous-système de stockage. Le sous-système de stockage doit conserver les informations de descripteur de sécurité pour chaque ressource de stockage. Pour implémenter l’authentification, les fournisseurs de stockage ont deux choix :

S’authentifier dans le sous-système (recommandé)
Authentifiez-vous dans chaque instance SMP.

Les deux options nécessitent une relation d’approbation établie entre le SMP et le sous-système de stockage afin que le descripteur de sécurité et les informations d’identité utilisateur puissent être transmis en toute sécurité.

Pour implémenter une authentification et une autorisation transparentes sur le sous-système de stockage, nous recommandons le lien entre le SMP et le sous-système de stockage pour implémenter Kerberos, NTLM ou SPNego. Si le sous-système de stockage a un serveur web en place, le protocole « NTLM sur HTTP » [MS-NLMP] peut être plus utile. Les fournisseurs de stockage peuvent choisir de conserver leurs protocoles propriétaires pour implémenter le modèle d’authentification unique. Toutefois, cette approche n’est pas recommandée, car elle peut entraîner plus de travail ou de configuration que l’implémentation d’un des protocoles d’authentification pris en charge par Windows.

Pour prendre en charge la stratégie de sécurité Windows, le sous-système de stockage doit obtenir les « informations de jeton » de l’utilisateur, qui incluent l’identificateur de sécurité de l’utilisateur (SID) et les SID de tous les groupes dont l’utilisateur est membre. Si le protocole Kerberos, NTLM ou SPNego est implémenté, le sous-système de stockage obtient les informations de jeton de l’utilisateur dans le cadre du protocole. Si le protocole propriétaire d’un fournisseur est utilisé entre SMP et le sous-système de stockage, le sous-système de stockage peut interroger les informations de jeton de l’utilisateur à partir d’Active Directory via le protocole LDAP (Lightweight Directory Access Protocol) et examiner l’attribut tokenGroupsGlobalAndUniversal ou l’attribut Object-Sid sur l’objet de compte de l’utilisateur.

Avec les informations de jeton de l’utilisateur, pour appliquer la stratégie de sécurité Windows, le sous-système de stockage doit implémenter l’algorithme Access Check décrit dans [MS-DTYP].

Si un fournisseur de stockage choisit de ne pas prendre en charge ce modèle d’authentification unique, nous vous recommandons de suivre le modèle de sécurité à partir de VDS , ce qui autorise uniquement les opérations lancées à partir de comptes d’administrateur. Toutefois, cette vérification doit maintenant être effectuée par le SMP lui-même.

Partager via