Cette section présente les informations suivantes :
Section 2.3.1, Conditions d'accès et de communication requises pour les workloads
Section 2.3.2, Conditions d'accès et de communication requises pour les conteneurs
Section 2.3.3, Exigences de port ouvert pour les hôtes du serveur PlateSpin
Section 2.3.4, Protection sur des réseaux publics et privés via NAT
Section 2.3.6, Conditions requises pour les grappes VMware DRS en tant que conteneurs
Le tableau ci-dessous liste les configurations logicielle, réseau et pare-feu requises pour les workloads que vous souhaitez protéger à l'aide de PlateSpin Protect.
Tableau 2-2 Conditions d'accès et de communication requises pour les workloads
|
Type de workload |
Conditions préalables |
Ports requis (valeurs par défaut) |
|---|---|---|
|
Tous les workloads |
Prise en charge de la fonctionnalité ping (demande et réponse d'écho ICMP) |
|
|
Tous les workloads Windows |
Microsoft .NET Framework version 2.0 ou 3.5 SP1 |
|
|
Windows 7 ; Windows Server 2008 ; Windows Vista |
|
TCP 3725 NetBIOS 137 - 139 SMB (TCP 139, 445 et UDP 137, 138) TCP 135/445 |
|
Windows Server 2003 (y compris SP1 Standard, SP2 Enterprise et R2 SP2 Enterprise) |
REMARQUE :après avoir activé les ports requis, exécutez la commande suivante au niveau de l'invite serveur afin d'autoriser l'administration à distance de PlateSpin : netsh firewall set service RemoteAdmin enable Pour plus d'informations sur netsh, consultez l'article Microsoft TechNet suivant : http://technet.microsoft.com/fr-fr/library/cc785383%28v=ws.10%29.aspx. |
|
|
Windows Server 2000 ; Windows XP |
WMI (RPC/DCOM) peut utiliser les ports TCP 135 et 445 ainsi que les ports aléatoires ou assignés dynamiquement supérieurs à 1024. Si des problèmes se produisent lors de l'ajout du workload, envisagez de le placer provisoirement dans une zone démilitarisée ou d'ouvrir temporairement les ports protégés par le pare-feu le temps d'ajouter le workload à PlateSpin Protect. Pour plus d'informations, telles que des conseils pour la limitation de la plage de ports pour DCOM et RPC, reportez-vous aux articles techniques Microsoft suivants. |
TCP 3725 NetBIOS 137 - 139 SMB (TCP 139, 445 et UDP 137, 138) RPC (TCP 135) |
|
Tous les workloads Linux |
Serveur Secure Shell (SSH) |
TCP 22, 3725 |
Le tableau ci-dessous liste les configurations logicielle, réseau et pare-feu requises pour les conteneurs de workloads pris en charge.
Tableau 2-3 Conditions d'accès et de communication requises pour les conteneurs
|
Système |
Conditions préalables |
Ports requis (valeurs par défaut) |
|---|---|---|
|
Tous les conteneurs |
Fonctionnalité ping (demande et réponse d'écho ICMP). |
|
|
VMware ESX/ESXi 4.1 VMware ESXi 5.0 |
|
HTTPS (TCP 443) |
|
vCenter Server |
L'utilisateur disposant de l'accès doit se voir accorder les autorisations et rôle appropriés. Pour plus d'informations à ce sujet, consultez la version correspondante de la documentation VMware. |
HTTPS (TCP 443) |
Voici les exigences de port ouvert auxquelles doivent répondre les hôtes du serveur PlateSpin
Tableau 2-4 Exigences de port ouvert pour les hôtes du serveur PlateSpin
|
Port (par défaut) |
Remarques |
|---|---|
|
TCP 80 |
Pour la communication HTTP |
|
TCP 443 |
Pour la communication HTTPS (si SSL est activé) |
Dans certains cas, une source, une cible ou PlateSpin Protect peut se trouver sur un réseau (privé) interne derrière un périphérique NAT (Network Address Translator) et être incapable de communiquer avec l'autre partie durant la protection.
PlateSpin Protect vous permet de résoudre ce problème, en fonction de l'hôte qui se trouve derrière le périphérique NAT :
Serveur PlateSpin : dans l'outil de configuration de votre serveur PlateSpin, indiquez les adresses IP supplémentaires assignées à cet hôte. Reportez-vous à la section Configuration de l'application en vue de son fonctionnement dans des environnements NAT.
Conteneur cible : lorsque vous essayez de découvrir un conteneur (tel que VMware ESX), spécifiez l'adresse IP publique (ou externe) de cet hôte dans les paramètres de découverte.
Workload : lorsque vous essayez d'ajouter un workload, spécifiez l'adresse IP publique (externe) de ce workload dans les paramètres de découverte.
VM de basculement : au cours du rétablissement, vous pouvez spécifier une adresse IP alternative pour le workload de basculement à la section Détails du rétablissement (Workload sur VM).
Cible de rétablissement : au cours d'une tentative d'enregistrement d'une cible de rétablissement, lorsque vous êtes invité à fournir l'adresse IP du serveur PlateSpin, renseignez soit l'adresse locale de l'hôte du serveur Protect, soit l'une de ses adresses (externes) publiques enregistrées dans l'outil de configuration du serveur PlateSpin (reportez-vous à la section Serveur PlateSpin ci-dessus).
Pour permettre au serveur PlateSpin de fonctionner dans des environnements NAT, vous devez enregistrer ses adresses IP supplémentaires dans la base de données de l'outil de configuration du serveur PlateSpin lue au démarrage.
Pour plus d'informations sur la procédure de mise à jour, reportez-vous à la section Configuration du comportement du serveur PlateSpin via les paramètres de configuration XML.
Par défaut, le serveur PlateSpin utilise le shell /bin/bash pour l'exécution de commandes sur un workload source Linux.
Si nécessaire, vous pouvez remplacer le shell par défaut en modifiant la clé de registre correspondante sur le serveur PlateSpin
Reportez-vous à l'article de la base de connaissances n° 7010676.
Pour être une cible de protection valide, vous devez ajouter votre grappe VMware DRS à l'ensemble de conteneurs (inventoriés) en tant que grappe VMware. ne tentez pas d'ajouter une grappe DRS en tant qu'ensemble de serveurs ESX distincts. Reportez-vous à la section Ajout de conteneurs (cibles de protection).
En outre, votre grappe VMware DRS doit respecter la configuration requise suivante :
DRS est activé et défini sur Partiellement automatisé ou Entièrement automatisé.
Les serveurs ESX de la grappe VMware partagent au moins une banque de données.
Au moins un vSwitch et un groupe de ports virtuel ou un commutateur distribué vNetwork sont communs à tous les serveurs ESX de la grappe VMware.
Les workloads de basculement (VM) pour chaque contrat de protection sont placés exclusivement sur les banques de données, les vSwitch et les groupes de ports virtuels partagés par tous les serveurs ESX de la grappe VMware.