Quelles sont les différences entre Prime Infrastructure (PI) et Data Center Network Manager (DCNM) ?
J’avais déjà écrit un billet au sujet de la complémentarité entre Prime LMS et DCNM, mais maintenant que Prime Infrastructure devient le remplaçant de LMS, la question m’est à nouveau posée régulièrement. En appliquant une simple relation transitive, on pourrait dire que “c’est pareil” …. sauf que Prime Infrastructure n’étant pas du tout pareil à LMS, la transitivité ne s’applique pas…. et qu’il convient de refaire le tour de la question … et comme souvent, tout est dans les détails …
Vous me suivez ?
Tout comme LMS, Prime Infrastructure (PI) supporte les équipements Nexus, MDS et UCS. Dans la documentation officielle des équipements supportés, on apprend que, pour tous les Nexus et MDS, les fonctions suivantes de PI sont supportées:
- configuration archive,
- image management,
- inventory (flash, image, interfaces, memory, physical inventory),
- performance monitoring (device availability, cpu, interface availability, memory, temperature)
- topology: CDP and LLDP neighbor discovery
En première lecture, on serait tenté de dire que “c’est bon, Prime Infrastructure fait le minimum”. Voyons cela en détails, et comparons avec DCNM
Découverte et inventaire
cliquer pour agrandir
Les Nexus et MDS sont effectivement découverts par Prime Infrastructure. Ils apparaissent dès lors dans le Device Workcenter, avec les détails de l’inventaire matériel. Mais les Nexus 2000 (Fabric Extender, FEX) sont vus exactement de la même manière qu’une carte dans un chassis Catalyst 6500. C’est conceptuellement correct, mais c’est un peu court … quand on sait l’importance des FEX dans une architecture Data Center. Concernant les Nexus 7000 et les VDC, chaque VDC est découvert par PI comme un Nexus 7000 à part entière, ce qui est vrai, mais il n’y a aucune information sur l’appartenance des VDC à un même châssis physique. Il en va de même pour tous les objets et concepts spécifiques des Nexus, tels que vPC, Port Profile, FabricPath, et autres VEM et VSM du Nexus 1000V. Toujours dans le Device Workcenter, l’onglet “Configuration” ne montre rien pour les Nexus, alors que pour tous les autres types d’équipement on peut au minimum visualiser et configurer les interfaces Ethernet.
Il va sans dire que DCNM découvre et fait l’inventaire complet de tous les composants physiques et logiques des Nexus et MDS, avec diverses présentations graphiques ou tabulaires de tous ces objets. Pour être honnête et exhaustif, précisons que DCNM-LAN ne gère pas le niveau 3 (VRF, protocoles de routages) et la QoS des Nexus
Vue topologique
C’est simple, il n’y a pas encore de vue topologique dans Prime Infrastructure. Du coté de DCNM, il y a pléthore de vues topologiques:
- dans le client DCNM-LAN Java: topologies physique, logique avec PortChannels et vPC, et de niveau 2 (avec VLANs et topologie et chemins FabricPath).
- dans le client DCNM-SAN Java: topologie complète d’une Fabric ou d’un VSAN, vue contextuelle du chemin des données entre un serveur et les baies de stockages utilisées.
- dans le client web, on retrouve des vues topologiques physiques animées avec des données de performance, et des vues contextuelles de la topologie entre ‘une Virtual Machine et ses volumes de disques.
Archivage des configurations
Prime Infrastructure archive correctement la configuration (startup et running) des Nexus, et il offre les mêmes fonctions d’affichage et de comparaison que pour tous les autres types d’équipements. Mais pour le rollback il le fait en “poussant” la configuration sur le Nexus…. Il n’utilise pas la fonctionnalité NX-OS native de checkpoint/rollback qui garanti l’intégrité et l’atomicité de la restauration…. DCNM, au contraire utilise cette fonction NX-OS.
Gestion des images NX-OS
A la différence de DCNM, Prime Infrastructure ne gère pas la spécificité des images NX-OS, avec les deux images (kickstart et system), et la fonction native d’upgrade dans NX-OS.
Gestion graphique de la configuration NX-OS
Cisco Prime Infrastructure affiche certains composants des Nexus dans le Device Workcenter (interfaces, memoire, modules, etc..) mais il ne permet aucune modification. Aucun des objets spécifiques Nexus (VDC, VPC, Port Profile, FEX, etc …) n’est visible dans Prime Infrastructure. DCNM-LAN propose une interface graphique pour (presque) toute la configuration NX-OS (sauf QoS et Layer 3 (VRF, Routage)), avec des “wizards” pour aider à la création ou modification des objets les plus complexes. DCNM-SAN fait de même pour les commutateurs SAN (Nexus et MDS), avec encore plus de wizards pour les taches les plus courantes et des outils de diagnostic.
Template de configuration NX-OS
Cisco Prime Infrastructure et DCNM proposent tous les deux un mécanisme de template de configuration. Mais le format des templates est différent et il n’est donc pas possible d’échanger les templates entre les deux produits. Les templates de Prime Infrastructure sont plus sophistiqués que ceux de DCNM, car ils sont écrits en XML et ils supportent un language de scripting ( Apache Velocity Template Language). Des améliorations très significatives vont encore arriver avec Prime Infrastructure 2.0
Performance Monitoring
Prime Infrastructure surveille la performance des équipements Nexus et MDS comme de n’importe quel autre type d’équipement. Les paramètres surveillés sont la charge CPU et mémoire du châssis, sa disponibilité, et le volume de trafic et les erreurs sur les interfaces. Cette collecte de mesures se fait en SNMP.
DCNM fait globalement la même chose, plus un monitoring détaillé qui permet de collecter pratiquement tous les compteurs des interfaces disponibles dans NX-OS. Ce monitoring détaillé convient mieux pour les situation de “troubleshooting”. DCNM possède également des mécanismes d’alarmes sur seuil qui permettent d’émettre une notification ou d’exécuter un script lorsqu’un seuil est dépassé.
Alarmes et évènements
Globalement, les deux produits collectent à la fois les syslogs et les traps SNMP, et sont capables de faire suivre les évènements vers un autre système.
Inventaire des serveurs/VM et Cisco UCS
Prime Infrastructure est capable de construire l’inventaire de tous les clients filaires et wifi qui sont connectés aux équipements administrés par PI. Cette fonction existait déjà dans Prime LMS sous le nom de “User Tracking” pour les équipements filaires et dans WCS pour l’inventaire des clients wifi. Cependant, cette fonction ne prend pas en compte les Nexus. Donc l’inventaire des serveurs du DataCenter n’est pas possible pour l’instant avec Prime Infrastructure.
cliquer pour agrandir
DCNM, depuis la dernière version 6.1.2, est capable de faire l’inventaire complet de tous les serveurs (physiques et virtuels) connectés sur les réseaux LAN et SAN du DataCenter. DCNM utilise et consolide les informations de plusieurs sources (LLDP, les tables ARP et IP des Nexus, le vCenter de VMWare). L’inventaire des serveurs/VMs est disponible de plusieurs manières dans l’interface de DCNM, avec des fonctions très efficaces de recherche et de filtrage (par IP, MAC, WWN, VLAN, switch, …).
cliquer pour agrandir
DCNM présente aussi une vue topologique contextuelle d’un serveur, c’est-à-dire une petite carte qui montre à quels commutateurs (LAN ou SAN) le serveur (ou la VM) est connecté. Pour le SAN, il est même possible d’afficher le chemin des données depuis le serveur jusqu’à la baie de stockage. Je vous présenterai en détails cette fonctionnalité dans un billet dédié.
Concernant les serveurs Cisco UCS, Prime Infrastructure inventorie les UCS Fabric Interconnect, mais ne va pas plus loin que l’inventaire très basique. DCNM effectue une découverte complète des UCS-B jusqu’aux blades, et affiche la topologie du réseau “à l’intérieur” de l’UCS.
En conclusion, cette comparaison détaillée montre que Prime Infrastructure est pour l’instant (version 1.3) assez limité dans ses capacités à administrer une infrastructure Nexus, et que DCNM est nécessaire pour l’administration complète du Data Center Cisco.
Tags:
