Ce document répond aux questions et aux préoccupations concernant l'installation du client de découverte Migration Center dans les centres de données. Il souligne l'importance de la sécurité, de la conformité et des performances lors de la découverte et de la collecte de données à partir des ressources informatiques des clients dans des environnements très réglementés.
Comment les données sont-elles collectées ?
Le client de découverte utilise plusieurs méthodes pour collecter des données à partir des machines cibles. Les données collectées varient en fonction de la méthode. Au niveau invité, les données sont collectées à l'aide de scripts de collecte. Au niveau de l'hyperviseur, elles sont collectées à l'aide des API de la plate-forme sous-jacente.
Service et processus du client de découverte
Le client Discovery s'exécute en tant que service appelé GoogleMCDC sous un processus appelé mcdc_service.exe.
Scripts de collecte
Toutes les méthodes de collecte au niveau invité utilisées par le client Discovery exécutent des scripts de collecte sur les machines cibles. Vous pouvez consulter les scripts réels utilisés pour la collecte en cliquant sur les liens suivants :
- Linux
- Windows
Les scripts de collecte stockent les résultats dans un fichier d'archive (zip ou tar) que le client de découverte récupère ensuite.
Mécanismes de collecte
Le client de découverte peut utiliser un ou plusieurs des mécanismes de collecte décrits dans les sections suivantes pour collecter des données à partir des machines cibles.
SSH (Linux)
Lors de la collecte SSH, le processus suivant se produit :
- Une session SSH est établie entre la machine du collecteur et le serveur cible.
- Un répertoire temporaire est créé sous
~/.mcdc-temp/. - Le script de collecte est copié dans ce répertoire.
- Le script de collecte est exécuté.
- L'archive de résultats est récupérée à l'aide de SCP.
- Le répertoire temporaire est nettoyé.
WMI (Windows)
Par défaut, le client de découverte utilise des appels WMI à distance pour collecter des données à partir des machines Windows cibles. Si vous activez la collecte basée sur un script, le client de découverte copie et exécute un script sur la machine cible.
Lors de la collecte WMI basée sur un script, le processus suivant se produit :
- Une connexion WMI est établie avec la machine cible.
- Une clé de registre temporaire (volatile) est créée sur la machine cible sous
HKLM:\SOFTWARE\Google\Collector\data. - Le script de collecte est copié dans la clé de registre.
- Un répertoire temporaire est créé sous
C:\temp. - Le script de collecte est écrit dans le répertoire temporaire.
- Le script de collecte est exécuté.
- Le résultat de la collecte est écrit dans la clé de registre volatile.
- Le résultat est copié sur la machine du collecteur.
VMware Guest Tools (Linux et Windows)
Lors de la collecte VMware pour Linux et Windows, le processus suivant se produit :
- Un répertoire temporaire est créé à l'aide des outils VMware pour l'invité.
- Le script de collecte est copié dans ce répertoire.
- Le script de collecte est exécuté.
- L'archive de résultats est récupérée à l'aide des outils VMware pour les invités.
- Le répertoire temporaire est nettoyé.
Collecte périodique des données
Le client de découverte collecte les données de tous les serveurs configurés de manière périodique. Il existe deux types de collections :
- Collecte complète : s'exécute une fois par jour pour chaque serveur. Cette collecte exécute le script de collecte complet qui collecte diverses informations sur la VM, telles que le matériel, l'environnement, les logiciels installés, les processus en cours d'exécution, etc.
- Collecte des performances : s'exécute toutes les 10 minutes sur chaque serveur. Cette collecte exécute le script de collecte des performances qui collecte des données sur l'utilisation du processeur, de la mémoire, du réseau et du disque.
Quelles sont les données collectées ?
Les scripts de collecte recueillent des données sur les VM cibles pour comprendre leur configuration et les ressources qu'elles utilisent. Cela les aide à évaluer et à planifier leur migration vers le cloud.
La liste suivante décrit les données collectées :
- Informations système : informations de base essentielles pour déterminer la taille de la VM, les exigences de performances et les dépendances vis-à-vis de matériel ou de pilotes spécifiques. Il inclut les éléments suivants :
- Système d'exploitation (version et édition)
- Matériel (processeur, mémoire, informations sur le BIOS)
- Configuration réseau (interfaces réseau, adresses IP, tables de routage)
- Stockage (lecteurs de disque, partitions, points de montage)
- Logiciels et services installés : les scripts collectent une liste des packages installés et des services en cours d'exécution pour comprendre la pile logicielle de la VM et son rôle. Il inclut les éléments suivants :
- Serveurs Web (Apache, Tomcat, JBoss)
- Bases de données (les preuves de SQL Server sont collectées dans le script Windows)
- Autres applications pouvant nécessiter des configurations spécifiques lors de la migration.
- Configurations d'application : les scripts collectent également les fichiers de configuration des serveurs Web (IIS, Apache, Tomcat, JBoss, WordPress). Cela permet de comprendre les paramètres et les dépendances spécifiques de ces applications, ce qui est essentiel pour assurer une transition fluide vers l'environnement cloud.
- Détection de l'environnement VMware et cloud : les scripts Linux et Windows tentent de détecter si la VM est déjà exécutée dans un environnement cloud (AWS ou Google Cloud) ou dans un cluster vCenter. Pour ce faire, ils envoient des requêtes aux serveurs de métadonnées de ces fournisseurs de services cloud. Si la VM se trouve déjà dans le cloud, les scripts collectent les métadonnées pertinentes, telles que l'ID et le type d'instance, ainsi que d'autres informations.
- Métriques de performances : les scripts de collecte des performances mesurent l'utilisation des ressources. Voici quelques exemples :
- Processeur
- Mémoire
- Opérations d'E/S
- Mise en réseau
- Connexions réseau : les scripts collectent les connexions ouvertes pour aider à créer une image des différentes dépendances sur les ressources réseau.
Impact sur les performances des machines cibles
Évaluation de l'utilisation des ressources
L'utilisation des ressources par les scripts de collecte sur la machine cible dépend de paramètres tels que le nombre de processus en cours d'exécution, le nombre d'applications déployées, le nombre de connexions réseau actives, etc.
Sous Windows, le script de collecte s'exécute avec la priorité la plus basse disponible via l'API Threading.
Sur Linux, une valeur nice de 5 est utilisée pour minimiser les interférences avec les charges de travail de production et s'assurer qu'elles ont une priorité plus élevée que le script de collecte.
Une collecte typique peut prendre entre 5 et 20 secondes d'utilisation élevée du processeur monocœur sur une machine non chargée. Cela peut prendre plus de temps si d'autres charges de travail sont présentes, car elles ont une priorité plus élevée.
Stratégies d'atténuation
Le client de découverte fournit un mécanisme permettant d'empêcher la collecte de serveurs spécifiques pendant des heures spécifiques. Cette fonctionnalité permet d'empêcher la collecte à partir de serveurs exécutant des charges de travail critiques pendant les heures de pointe.
Points à noter concernant la sécurité
Authentification et autorisation
Communication avec les machines cibles
- Le client Discovery utilise des canaux sécurisés pour s'authentifier et communiquer avec les machines cibles. Cela inclut les connexions SSH, WMI, VMware Tools et vCenter. Le client de découverte utilise les mesures de sécurité intégrées à ces protocoles.
- Dans SSH, le client de découverte autorise l'authentification par nom d'utilisateur et mot de passe, ainsi que l'authentification par clé. Pour obtenir la liste complète des types de paires de clés acceptés, consultez Exigences concernant les ressources cibles.
Communication avec Google Cloud
- Les clients de découverte enregistrés communiquent avec Google Cloud Migration Center lors de leur fonctionnement normal. La communication s'effectue via un compte de service avec la liaison de rôle
roles/migrationcenter.discoveryClient. Le compte de service est créé automatiquement ou fourni par l'utilisateur lors de l'inscription. - La clé privée du compte de service est chiffrée sur la machine cliente Discovery à l'aide du mécanisme de chiffrement décrit dans la section suivante.
- Toutes les communications avec Google Cloud sont authentifiées à l'aide de ce compte de service et chiffrées à l'aide de SSL/TLS.
Chiffrement des données
- En transit : tous les canaux de communication du client Discovery utilisent le chiffrement pour protéger les données en transit. Cela inclut la communication avec les machines cibles à l'aide des différents protocoles (SSH/WMI) et la communication avec Google Cloud à l'aide de HTTPS.
- Au repos : les informations permettant d'identifier personnellement l'utilisateur, les informations permettant d'identifier personnellement l'utilisateur sensibles et les secrets du client de découverte sont tous chiffrés au repos à l'aide de l'algorithme
AES128_GCMet de l'API de protection des données Windows (DPAPI) pour stocker les clés de chiffrement de manière sécurisée.
Détection et prévention des intrusions (IDS, Intrusion Detection System, et IPS, Intrusion Prevention System)
Étant donné que le client Discovery est utilisé pour se connecter et exécuter des scripts sur de nombreuses VM de votre organisation, il peut déclencher des alertes EDR ou xDR. Cela dépend fortement de la façon dont vos outils de sécurité sont configurés et des outils spécifiques que vous utilisez. Soyez vigilant et envisagez de créer des exemptions pour les alertes et les appareils spécifiques.
Journalisation et compatibilité
Le client de découverte collecte des journaux pendant son fonctionnement pour permettre le débogage et l'assistance. Les journaux du client de découverte sont collectés à l'aide de deux mécanismes :
- Journaux locaux : les journaux sont écrits dans un fichier sous
C:\ProgramData\Google\mcdc\logs. Les fichiers journaux sont alternés et compressés. - Journaux Cloud : les clients enregistrés envoient également les journaux à Google Cloud afin qu'ils puissent être utilisés par l'équipe d'assistance Google Cloud lorsque des problèmes sont signalés par les clients.