Tagged: VSAN

vSphere 7.0 U1 : Nouveautés

Jetons un coup d’œil aux nouvelles fonctionnalités et améliorations du VMware vSphere 7.0 U1

vSphere Clustering Service (vCLS)

Le service de clustering vSphere (vCLS) permet d’utiliser les services de clustering et DRS sans avoir besoin de la disponibilité de vCenter Server pour ses opérations et ses configurations.

Cela signifie que même lorsque vSphere High Availability (HA) ou vCenter Server High Availability (VCHA) n’est pas disponible, vCLS fonctionnera toujours car il utilise ses propres agents VMs système.

Ces petits agents de VM fonctionneront comme un quorum de cluster :

  • Le nombre d’agents de VM système est de 3
  • Pour les clusters avec moins de 3 hôtes ESXi, les agents de VM sont égaux au nombre d’hôtes ESXi dans le cluster.

Même si vous supprimez ou mettez hors tension par erreur ces agents VM système, vCLS les recréera / rallumera automatiquement.

vSphere Lifecycle Manager (vLCM)

vLCM a été lancé avec 7.0, mais maintenant, en plus de la possibilité de mettre à jour ou de mettre à niveau les hôtes vSphere et vSAN, il est également possible de l’utiliser pour la configuration NSX.

NSX-T

La gestion des clusters et des nœuds NSX-T ne serait possible que dans les futures versions de NSX-T.

Il sera possible d’utiliser vLCM via NSX Manager et de gérer tous les aspects du cycle de vie de NSX-T.

Vous pourrez mettre à jour ou mettre à niveau votre NSX-T Cluster avec la remédiation de vos nœuds de cluster.

vSAN

Prise en compte de vSAN fault domains pour une mise à jour intelligente avec vLCM.

vLCM peut effectuer des mises à jour en respectant les zones de disponibilité tout au long du processus de cycle de vie des mises à jour.


vSphere Lifecycle Manager (vLCM) est conscient des topologies vSAN telles que les fault domains vSAN et de zone de disponibilité.

Certains des produits qui sont pris en charge lors de l’utilisation de vSphere Lifecycle Manager avec vSphere 7.0 U 1 :

  • Prise en charge de NSX-T (à partir des prochaines versions de NSX-T)
  • Prise en charge de vSAN
  • Intégration Firmware pour Lenovo ThinkAgile VX series

vSphere with Tanzu Kubernetes Grid (TKG)

vSphere with Tanzu a été introduit dans vSphere 7.0, mais maintenant la plus grande nouveauté avec TKG est que nous pouvons désormais l’utiliser dans vSphere sans avoir besoin d’utiliser le package VMware Cloud Foundation (comprenait vSphere, NSX-T et vRealize). 

Dans cette nouvelle version, il sera possible d’implémenter Kubernetes directement avec vSphere et d’utiliser les applications et les conteneurs.

Les administrateurs peuvent désormais utiliser leurs propres solutions :

  • Réseau (pas nécessairement NSX) en utilisant des vSwitches distribués pour fournir un réseau à Kubernetes.
  • Stockage (pas nécessairement vSAN ) à l’aide de vos banques de données vSphere.

Scalability : hosts et VMs

Avec cette nouvelle mise à jour, il sera possible d’avoir d’énormes VM avec 768 vCPU et 24 To de mémoire.

vSphere Cluster aura la possibilité d’avoir un maximum de 96 hôtes ESXi par cluster, il s’agit d’une augmentation de 50% par rapport à la capacité actuelle d’un cluster.

Remarque: cela concerne uniquement vSphere Cluster, pour vSAN, le maximum est toujours de 64 hôtes ESXi par cluster.

Les hôtes ESXi disposeront également d’un maximum de 24 Tb de mémoire physique, ces modifications sont disponibles uniquement avec le nouveau Virtual Hardware v18.

vSphere 7.0 U1 : vSphere Scalability

vCenter Connect

vCenter Connect vous permet de connecter votre vCenter à tous vos environnements vCenter on-premise, à distance et Cloud Partner (comme VMware sur AWS, sur Azure, IBM).

À partir d’un point de gestion central, les clients auront la possibilité de gérer l’ensemble de l’infrastructure VMware.

vSphere 7.0 U1 : vCenter Connect

Aperçu des nouvelles fonctionnalités de vSphere 7.0 U1

YouTube player

Service de fichiers vSAN [vSAN File Services]

Service de fichiers vSAN est l’une des nouveautés de la version 7.

Les Service de fichiers vSAN permettent la configuration de partages SMB ou NFS, de sorte que VSAN peut évidemment devenir un serveur de fichiers.

Il s’agissait d’une fonctionnalité qui permet de fournir le stockage aux applications basées sur des conteneurs exécutées dans des clusters vSphere et également fourni un élément clé pour servir des applications cloud natives dans vSAN.

Le service de fichiers VSAN est fourni via les VM Photon OS, également appelées VM agent, qui sont des appliances virtuelles très légères exécutant Photon OS et Docker.

Les machines virtuelles d’agent exécutent des serveurs NFS et fournissent un accès aux partages de fichiers.

Les administrateurs n’ont pas à se soucier de ces machines virtuelles, pas de correctifs, pas de gestion VM Tools, etc…

Si une telle machine virtuelle est supprimée accidentellement, le système la recrée automatiquement.

Configuration

Une fois connecté au niveau vCenter Server via le client Web vSphere, sélectionnez le cluster vSAN> > Configure > vSAN > Services.

Au niveau vSAN services, Activer le service (File Service) pour démarrer l’assistant de configuration.

Service de fichiers vSAN configuration

Architecture

Service de fichiers vSAN Architecture

Prérequis

  • CPU: les nœuds de fichier vSAN nécessitent 4 processeurs virtuels, l’hôte doit donc avoir un processeur avec au moins 4 cœurs, sinon vous obtiendrez des messages d’erreur.
  • Adresse IP statique et enregistrements DNS:
    • vous devrez créer des enregistrements DNS directs et inversés pour les nœuds des services de fichiers vSAN.
    • Une Adresse IP statique est requis pour les serveurs de fichiers.
  • Domaine AD:
    • vous devrez également fournir des informations sur votre domaine AD pour le partage SMB et le partage NFS avec la sécurité Kerberos.
    • En outre, un compte d’utilisateur avec des autorisations suffisantes est requis.

Démonstration Service de fichiers vSAN

YouTube player

vSAN HCI Mesh

vSAN HCI Mesh (également appelé Maillage HCI) est l’une des nouvelles fonctionnalités introduites avec la version vSAN 7 Update 1.

Le Maillage HCI assure la désagrégation du calcul et du stockage en permettant aux clients vSAN de partager des banques de données vSAN entre deux ou plusieurs clusters.

Les administrateurs vSAN peuvent configurer une relation entre plusieurs clusters et autoriser ces clusters à partager la capacité de la banque de données vSAN.

En utilisant vSAN HCI Mesh, vous pouvez maintenant monter la banque de données distante et l’utiliser comme s’il s’agissait d’une banque de données locale.

VMware-vSAN-HCI-Mesh-architectural-overview What is VMware vSAN HCI Mesh?
Quelques exemples de cas d’utilisation (Use case) :
  • Vous avez un cluster hybride et un cluster 100% Flash et vous souhaitez provisionner une VM sur le cluster hybride, tout en profitant des avantages du stockage 100% Flash.
  • Vous avez deux clusters, le premier (Cluster X) n’a plus de stockage disponible et le second (Cluster Y) est plein côté calcul et vous devez déployer de toute urgence une VM pour répondre à un besoin métier, dans ce cas vous pouvez créer la VM sur le cluster X (utilisation de la capacité de calcul) en pointant vers la base de données du cluster Y (utilisation du stockage disponible).

Cette fonctionnalité utilise l’adaptateur vSAN VMKernel natif et le protocole RDT pour communiquer dans la topologie HCI maillée avec d’autres nœuds vSAN.

 La grande différence entre une banque de données vSAN « locale » et un maillage HCI réside dans le fait que « DOM Client » et « DOM Owner » ont été séparés.

Donc au lieu d’avoir le « DOM Owner » localement, il est maintenant distant sur le cluster distant.

vSAN HCI Mesh

VMware vSAN HCI Mesh offre certainement la capacité nécessaire pour satisfaire de nombreux cas d’utilisation différents.

Les capacités de désagrégation apportées par vSAN HCI Mesh dans vSAN 7 Update 1 permettront aux clients d’utiliser plus efficacement le stockage dans les environnements vSAN.

Cela facilitera le regroupement des ressources disponibles, notamment le calcul et le stockage sur de nombreux clusters différents (Disaggregated cross cluster architecture).

YouTube player

vSAN Performance Monitor

vSAN Performance Monitor est un outil de surveillance basé sur les métriques de performances vSAN.

Il collectera périodiquement les performances de vSAN et d’autres mesures à partir des clusters vSAN.

Les données collectées sont visualisées de manière plus efficace et conviviale.

vSAN Performance Monitor est fourni avec des tableaux de bord préconfigurés qui aideront les clients à évaluer les performances des clusters vSAN, identifier et diagnostiquer les problèmes.

Ces tableaux de bord sont fortement inspirés de vSAN Observer.

Le moniteur est fourni dans une appliance virtuelle avec trois composants principaux, à savoir :

  • Telegraf: l’agent qui collecte les métriques du cluster vSAN et les stocke dans InfluxDB
  • InfluxDB: la base de données pour stocker les métriques
  • Grafana: Nous utilisons Grafana comme frontend pour virtualiser les métriques stockées dans InfluxDB
vSAN Performance Monitor Aarchitecture

Une fois déployés, les utilisateurs devront pointer le collecteur vers les clusters vSAN cibles et démarrer le service.

Après cela, les données seront collectées périodiquement et peuvent être visualisées sous forme de tableau de bord.

Ci-après un exemple de tableau de bord de vSAN Performance Monitor :

vSAN Performance Monitor tableau de bord
Téléchargement

L’outil est disponible au téléchargement via : URL

Modèle de licence par CPU de VMWare

VMware à annoncé une mise à jour importante du modèle de licence par CPU (per-CPU licensing model), afin de continuer à répondre aux besoins des clients dans un paysage industriel en évolution.

Nous aurons maintenant besoin d’une licence pour couvrir jusqu’à 32 cœurs physiques.

Si un CPU a plus de 32 cœurs, des licences supplémentaires seront nécessaires.

L’annonce du modèle de licence par CPU s’inscrit dans la continuité du parcours de VMware visant à aligner ces offres de produits sur les modèles de tarification standard du secteur.

Ce changement rapproche VMware du modèle de tarification standard basé sur le processeur adopté sur le marché.

Par conséquent, cette approche permettra aux clients de comparer plus facilement les licences et les prix entre VMware et les autres fournisseurs (en utilisant la tarification par cœur).

Cela aide VMware également à maintenir des tarifs simples et pertinents par rapport à l’évolution du marché du matériel.

Ce changement n’aura probablement aucun impact sur la grande majorité des clients actuels, car ils utilisent des serveurs Intel et AMD qui sont au niveau ou en dessous du seuil de 32 cœurs.

Tout client qui achète des licences logicielles VMware, pour un déploiement sur un serveur physique avec plus de 32 cœurs par CPU, avant le 30 avril 2020 sera éligible pour des licences supplémentaires gratuites par CPU pour couvrir les processeurs sur ce serveur.

Quelques exemples:
Modèle de tarification par  CPU
Produits concernés

La mise à jour des licences par CPU aura un impact sur toutes les offres VMware qui utilisent le processeur comme métrique de licence.

Voici une liste partielle des produits concernés par la nouvelle politique de licence:

  • VMware Cloud Foundation
  • VMware Enterprise PKS
  • VMware EVO:RAIL General Purpose Suite
  • VMware HCI Kit
  • VMware HCX
  • VMware Integrated OpenStack
  • VMware NSX Data Center
  • VMware SDDC Manager
  • VMware Site Recovery Manager
  • VMware vCenter Site Recovery Manager
  • VMware vCloud Director
  • VMware vCloud NFV Bundle
  • VMware vCloud NFV OpenStack Bundle
  • VMware vCloud Suite
  • VMware vRealize Automation
  • VMware vRealize Code Stream
  • VMware vRealize Network Insight
  • VMware vRealize Suite
  • VMware vRealize Log Insight
  • VMware vSAN
  • VMware vSphere
  • VMware vRealize Operations Manager
  • vRealize Business
  • vRealize Hyperic

CLOMD : Cluster Level Object Manager Daemon)

CLOMD est l’acronyme de Cluster Level Object Manager Daemon.

CLOMD est un service qui joue un rôle clé dans le fonctionnement du cluster vSAN.

Il s’exécute sur chaque hôte ESXi du cluster vSAN et est responsable :

  • La création de nouveaux objets
  • Le lancement de la réparation des objets existants après des pannes
  • Tous les types de déplacements et d’évacuations de données tels que le mode de maintenance de l’hôte vSAN,
  • L’évacuation des données lors de la suppression du disque vSAN,
  • Il maintient également l’équilibre du cluster vSAN et déclenche le rééquilibrage et la mise en œuvre des changements de stratégie.

Vous pouvez vérifier manuellement l’état du service via SSH au niveau du nœud ESXI, exemple :

CLOMD : Cluster Level Object Manager Daemon)

Contrôle d’admission vSphere HA

vSphere HA utilise le contrôle d’admission pour s’assurer que des ressources suffisantes sont disponible dans un cluster VMware pour assurer la disponibilité des machine virtuelles en cas de basculement à cause d’une de défaillance d’un hôte.

La base du contrôle d’admission vSphere HA est le nombre de défaillances d’hôte que le cluster est autorisé à tolérer (FTT : Number of Failures to Tolerate).

Trois types de contrôle d’admission sont disponibles :

types de contrôle d'admission

Pourcentage de ressources de cluster

Avec ce type de contrôle d’admission, vSphere HA vérifie qu’un pourcentage spécifié de ressources CPU et Mémoire est réservé pour le basculement.

Lorsque l’option de pourcentage de ressources de cluster est configurée, vSphere HA implémente le contrôle d’admission comme suite :

  1. Calcule les besoins en ressources pour toutes les machines virtuelles sous tension dans le cluster.
  2. Calcule les ressources disponibles au niveau des hôtes pour les machines virtuelles.
  3. Calcule la Capacité CPU et Mémoire nécessaire au basculement du cluster.
  4. Détermine si la Capacité CPU et Mémoire requis pour le basculement sont inférieures ou non à la Capacité de basculement configurée correspondante (spécifiée par l’utilisateur).

Prenons l’exemple suivantes pour un cluster VMware :

  • Un cluster de trois hôtes ESXI, ayant la configuration mémoires et CPU :
Hôtes ESXI CPU (Ghz) Mémoire (Go) disponible
H1 9 9
H2 9 6
H3 6 6
  • Il y a cinq machines virtuelles sous tension dans le cluster avec des besoins en CPU et en mémoire différents :
Machine Virtuelle CPU (Ghz) Mémoire (Go)
VM 1 2 1
VM 2 2 1
VM 3 1 2
VM 4 1 1
VM 5 1 1
  • La capacité de basculement configurée pour le processeur et la mémoire est de 25 %.
Pourcentage de ressources de cluster

Les ressources totales requises pour les machines virtuelles sous tension sont de 7 Ghz et 6 Go.

Le total des ressources hôte disponibles pour les machines virtuelles est de 24 Ghz et 21 Go. À partir de là, la capacité de processeur actuelle pour le basculement est de 70% ((24 Ghz – 7 Ghz)/24 Ghz). De même, la capacité de mémoire de basculement actuelle est de 71% (21 Go – 6 Go) / 21 Go).

Étant donné que la capacité de basculement configurée pour le cluster est de 25%, 45% des ressources CPU et 46% des ressources de mémoire sont toujours disponibles.

Stratégie d’emplacement

vSphere HA garantit que même si un nombre spécifié d’hôtes est défaillant, il reste suffisamment de ressources sur le cluster pour permettre le basculement de toutes les machines virtuelles à partir de ces hôtes. .

Donc, vSphere HA effectue le contrôle d’admission comme suit:

  1. Calculez la taille de l’emplacement. (Un emplacement est une représentation logique de la mémoire et CPU).
  2. Détermine le nombre d’emplacements pouvant être présents sur chaque hôte du cluster.
  3. Détermine la capacité de basculement actuelle du cluster.
  4. Détermine si la capacité de basculement actuelle est inférieure à la capacité de basculement configurée (spécifiée par l’utilisateur).

Nous allons illustrer par un exemple la méthode de calcul de la taille d’emplacement et son utilisation avec cette stratégie de contrôle d’admission, Considérez les hypothèses suivantes :

  • Le cluster est composé de trois hôtes, chacun avec différentes quantités de CPU et de mémoire disponibles. Le premier hôte (H1) à 9 Ghz de ressources processeur et 9 Go de mémoire disponible. Le second (H2) à 9 Ghz de CPU et 6 Go de mémoire disponible et le troisième (H3) à 6 Ghz de CPU et 6 Go de mémoire disponible.
  • Cinq machines virtuelles actives du cluster ont des exigences différentes en matière de processeur et de mémoire. VM1 nécessite 2 Ghz de ressources de processeur et 1 Go de mémoire, alors que VM2 nécessite 2 Ghz et 1 Go, VM3 nécessite 1 Ghz et 2 Go, VM4 nécessite 1 Ghz et 1 Go, VM5 nécessite 1 Ghz et 1 Go.
  • Le nombre de défaillance d’hôte tolérées par le cluster sont définies sur la valeur 1.
Stratégie d'emplacement

1– La taille d’emplacement est calculée en comparant à la fois les exigences de CPU et de mémoire des machines virtuelles et en sélectionnant la plus élevée.

Le besoin en CPU le plus élevé (partagé par VM1 et VM2) est de 2 GHz, tandis que le besoin en mémoire le plus élevé (VM3) est de 2 Go. Partant de là, la taille d’emplacement se compose d’un CPU de 2 GHz et d’une mémoire de 2 Go.

2– Le nombre maximum d’emplacements pouvant être pris en charge par chaque hôte est déterminé.

H1 peut prendre en charge quatre emplacements. H2 peut prendre en charge trois emplacements (le plus bas de 9 GHz/2 GHz et 6 Go/2 Go) et H3 peut aussi en prendre en charge trois.

3- La Capacité de basculement actuelle est calculée.

Le plus gros hôte est H1 et s’il est défectueux, le cluster contient toujours six slots, ce qui est suffisant pour les cinq machines virtuelles sous tension. Si H1 et H2 sont défectueux, il ne reste que trois emplacements, ce qui est insuffisant. Par conséquent, la Capacité de basculement actuelle est de 1.

Le cluster a un slot disponible (les six slots de H2 et H3 moins les cinq slots utilisés).

Hôtes de basculement dédiés

vSphere HA peut être configuré pour désigner des hôtes ESXI spécifiques comme hôtes de basculement. Avec le contrôle d’admission sur les hôtes de basculement dédiés, en cas de défaillance de l’hôte, vSphere HA tente de redémarrer ses machines virtuelles sur les hôtes de basculement prédéfinis. vSphere HA peut être configuré pour désigner des hôtes ESXI spécifiques comme hôtes de basculement. Avec le contrôle d’admission sur les hôtes de basculement dédiés,

Si cela n’est pas possible parce que les hôtes de basculement sont en panne ou que leurs ressources sont insuffisantes, vSphere HA tente de redémarrer ces VMs sur d’autres hôtes du cluster.

Pour que les fonctionnalités restent disponibles sur un hôte de basculement, vous ne pouvez pas mettre les machines virtuelles sous tension ni utiliser vMotion pour migrer des machines virtuelles vers un hôte de basculement.

De plus, DRS n’utilise pas d’hôte de basculement pour l’équilibrage de la charge.

VSANTOP Command-Line Tool

Avec la publication de vSphere 6.7 U3 et de vSAN 6.7 U3, VMware a ajouté un nouvel outil de ligne de commande VSANTOP.

L’outil s’exécute sur les hôtes ESXi pour afficher les mesures de performance vSAN en temps réel.

VSANTOP vous permet de surveiller et de dépanner les performances vSAN à un niveau très granulaire.

Ce nouvel outil pratique peut aider les administrateurs et le support VMware à résoudre les problèmes liés à l’environnement vSAN.

Lien de la documentation officielle

L’utilisation de l’outil est assez simple : démarrer une session SSH sur l’un des hôtes ESXi membre du cluster vSAN et taper : vsantop (en minuscule).

[root@esxi:~] vsantop

Pour afficher les différentes vues et mesures de performances dans vsantop, entrez les commandes suivantes :

VSANTOP commandes

vSphere 6.7 Update 3

VMware a annoncé la nouvelle version du produit vSphere, VMware vSphere 6.7 Update 3.

Cette nouvelle version de vSphere inclut de nouvelles fonctionnalités pour des opérations simplifiées et des performances accrues.

Mulitiple NVIDIA vGPUs per VM

VMware vSphere 6.7 Update 3 introduira la prise en charge de plusieurs GPU virtuels NVIDIA GRID (vGPU) par machine virtuelle.

Vous pouvez configurer jusqu’à quatre vGPU NVIDIA connectés à une machine virtuelle, ce qui permet d’améliorer les graphiques et les performances des applications.

Mulitiple NVIDIA vGPUs per VM

AMD EPYC Generation 2 Support

vSphere 6.7 update 3 est désormais compatible avec la 2e génération de processeurs AMD EPYC ™.

Ability to change vCenter Server PNID

PNID (Primary Network IDentifier of vCenter Server) est le nom du système défini lors du déploiement de vCenter Server.

La recommandation générale consiste à utiliser le nom (FQDN), toutefois, il n’a pas été possible de modifier le nom FQDN appelé (PNID) de vCenter Server dans les versions précédentes de vSphere.

Heureusement, la version 6.7 Update 3 offre la possibilité de renommer le nom PNID.

NB : Le nom PNID peut être mise à jour à partir de l’interface VAMI (Virtual Appliance Management Interface).

 l'interface VAMI (Virtual Appliance Management Interface).
PNID.

Dynamic DNS support

Lorsque VCSA (vCenter Server Appliance) est installé avec une adresse IP dynamique basée sur un serveur DHCP, une fois l’adresse IP de VCSA modifiée, les enregistrements DNS doivent être mis à jour manuellement.

Avec vSphere 6.7 Update 3, l’utilisation du Dynamic DNS est prise en charge, ce qui permet au VCenter Server de pouvoir enregistrer et mettre à jour de manière dynamique ces enregistrements sur les serveurs DNS.

Driver Enhancements

Plusieurs améliorations ont été apportées à la version 4 du pilote VMXNET3, telles que:

  • Guest encapsulation offload and UDP.
  • ESP RSS support to the Enhanced Networking Stack (ENS).
  • RSS on UDP.
  • ESP packets run on demand.

De plus, les pilotes suivants ont été mis à jour:

  • VMware nvme
  • Microchip smartpqi
  • Marvell qlnativefc
  • Broadcom lpfc/brcmfcoe
  • Broadcom lsi_msgpt2
  • Broadcom lsi_msgpt35
  • Broadcom lsi_msgpt3
  • Broadcom lsi_mr3
  • Intel i40en
  • Intel ixgben
  • Cisco nenic
  • Broadcom bnxtne

vSAN 6.7 Update 3

VMware continue d’améliorer vSAN, avec des fonctionnalités supplémentaires, une efficacité accrue et une gestion simplifiée dans vSAN 6.7 Update 3.

Managed Object Browser (MOB)

Managed Object Browser (MOB), est une interface graphique intégrée aux systèmes ESXi et vCenter.

Cet utilitaire vSphere vous permet de parcourir les informations détaillées sur des objets tels que des machines virtuelles, des banques de données et des pools de ressources.

Vérification de l’état du MOB

Pour vérifier si MOB est activé, ouvrez un navigateur et entrez http://x.x.x.x/mob (remplacez x.x.x.x par l’adresse IP de vCenter Server ou de votre hôte ESXi).

  • Si MOB est activé, le serveur vous invitera à saisir vos informations d’identification.
  • Sinon (non activé), le serveur affiche l’erreur « HTTP 503 – Service Unavailable ».

Par défaut, MOB est désactivé dans vSphere 6.x et doit être activé manuellement.

Activation de MOB à l’aide de vSphere Client

Se connecter à l’hôte ESXI via le vSphere Web Client.

Cliquer sur Gérer ==> Système ==> Paramètres avancés et Sélectionner la clé Config.HostAgent.plugins.solo.enableMob et activez-la.

Pour plus de détails : https://kb.vmware.com/s/article/2108405

Managed Object Browser (MOB)

Accès au Managed Object Browser

Une fois activé, MOB est accessible depuis un navigateur Web.

  • Ouvrez un navigateur Web.
  • Entrez le nom (FQDN) ou l’adresse IP du vCenter ou de l’hôte ESXi avec le suffixe « /mob ». (Exemple : https://192.168.192.131/mob)
  • Entrez votre nom d’utilisateur et mot de passe.
Managed Object Browser (MOB)
Badr Eddine CHAFIQ