Génération Ultra Sparc : Model ULTRA SPARC I Workstation Ultra 1 Ultra 2 Workgroup Servers Midrange Servers High End Servers 3000 ( 4 proc x 2) 4000 (7 proc x 2) 5000 (7 proc x 2 ) 6000 ( 14 proc x 2) 10K ( 16 SB, 16 D Introduction Technolgie Cross Bar) ULTRA SPARC II (Peu de Sbus, Beaucoup de PCI) Ultra 5 Ultra 10 Ultra 30 Ultra 60Ultra 80 1 proc 2 proc 4 proc Sun Blade 100 E250 E220 R 2 proc 2 proc E450 E420R 4 proc 4 proc 3500 4500 SBUS + PCI 5500 SBUS + PCI 6500 (Introduction DR) ULTRA SPARC III (Solaris 8 +, Bus Pci / Fcal pour Disks) Sun Blade 1000 Sun Blade 2000 SF280 SF480 SF880 SF1280 SF 3800 (2 SB x 4proc) SF 4800 (3 SB x 4proc) SF 4810 (3 SB x 4proc) SF6800 (6 SB x 4proc) 15 K 18SB, 18D, 102 proc 17 IOB, 576 GB mem 12 K c’est la moitié du 15 K Génération Ultra Sparc III : Ultra Sparc III et d’ordre de fréquence entre 600/750 MHZ Ultra Sparc III+ et d’ordre de fréquence entre 900/1050 MHZ Ultra Sparc III++ et d’ordre de fréquence de 1200 MHZ voir plus Mixage entre les CPU : Nous pouvons mixer les processeurs mais sous certaines conditions : Ultra III : Doit fonctionner avec la même fréquence sur toute la plateforme celle du plus petit. Ultra III+ : Doit avoir la même fréquence dans un même domaine Note : Les cartes systèmes à partir du 3800 jusqu’au 15K sont identiques. Définition de la notion de SMP : Symétriques multiprocesseurs, tous les CPU voient toutes la mémoires du système et y accèdent avec le même temps d’accès. Chaque CPU support de bank de mémoire, et chaque bank physique supportent 2 bank logique Chaque bank consistent en quatres DIMM. MMU : Composant hardware qui contient du code et un espace data pour optimiser la gestion de la mémoire. Maintenant la MMU est directement intégré dans le CPU. Il existe un lien physique « Electrique » entre la mémoire et la MMU ce qui fait que si nous perdons un processeur nous perdrons également la mémoire qui est rattaché au CPU. Configuration de la mémoire : Les cartes Systèmes possèdent 4 CPU et 32 emplacements DIMM. Les emplacements DIMM sont divisés en 8 Bank physique, chaque bank physique consistent en 4 DIMM. Lorsque de la mémoire est installé, tous les emplacements DIMMs dans un bank physique doivent être remplis ‘les 4’. L’architecture Snoopy Bus : Dans un Système de type SMP, à mémoire partagé, il doit y exister une cohérence entre les caches des CPU. Le snooping Bus est le même principe que le snooping réseaux. Les caches des processeurs sont à l’écoute les uns les autres et dès qu’une opération « Instruction » est effectuée il est automatiquement synchronisé avec les autres processeurs. Grâce à cette approche tous les CPU supervise les adresses de toutes les transactions qui mettront à jours les adresses qu’ils possèdent déjà. Les cartes de commutations (Répéteur): Les cartes de commutations servent aux transferts des données et de s adresses. Dans les serveurs MidFrame la charge utile de données consiste en 288 bits (266 bits de données et 32 bits de parités). Les cartes I/O PCI : Les cartes d’I/O pci sont dirigé par 2 contrôleur Schizo (0,1). Chaque Schizo contient 2 bus Pci, 1 à 66Mhz (Enhanced pci) et l’autre à 33 Mhz. Les serveurs 4800, 4810, 6800 supportent les cartes d’I/O cPCI à 4 emplacements Le modèle SunFire 3800 supporte uniquement les cartes d’I/O cpi à 6 emplacements Buts de la Gamme SunFire MidFrame : La gamme des Sun Fire MidFrame forme une famille de systèmes multiprocesseurs à mémoire SMP. Les Serveurs MidFrame on des caractéristiques de mainframe, telle l’utilisation des domaines dynamiques et des segments. Il existe 4 modèles de SunFire MidFrame : Le Serveur Sun Fire 3800 Le Serveur Sun Fire 4800 Le Serveur Sun Fire 4810 Le Serveur Sun Fire 6800 Le Serveur Sun Fire 3800 : Vous pouvez placer jusqu'à 3 plateformes 3800 dans un rack standard. Il a été conçu Pour les fonctions suivantes : Serveur de Base de données, serveur d’application, serveur de messagerie, … Il possède les caractéristiques suivantes : Redondance matérielle Support jusqu'à Huit processeurs Support jusqu'à 64 GB de mémoire à correction ECC 12 emplacements HOT SWAP PCI Support 2 domaines Max Le Serveur Sun Fire 4800 : Le serveur Sun Fire 4800 a été conçu pour les fonctions suivantes : Serveur de Base de données, serveur d’application, serveur de messagerie, … Il possède les caractéristiques suivantes : Redondance matérielle totale Support jusqu'à 12 processeurs Support jusqu’à 96 GB de mémoire 16 emplacement I/O PCI ou 8 emplacement HOT SWAP CPCI ou une combinaison des 2 avec 1 emplacement de 8 PCI et de 4 CPCI Support jusqu'à 2 domaines Le Serveur Sun Fire 4810 : Le serveur Sun Fire 4810 est un serveur qui a été conçu pour l’armé. Il est identiques que le 4800 sauf, qu’il est mieux adapter pour être transporté dans des camions, avion, bateaux… Le Serveur Sun Fire 6800 : Le serveur Sun Fire 6800 est un serveur hautement disponible, il a été conçu pour les applications suivantes : Serveur d’application, Serveur de calcul, serveur de messagerie, … Il possède les caractéristiques suivantes : Redondance matérielle totale Support jusqu'à 24 processeurs UltraSparc III Support jusqu’à 192 GB de mémoire 32 emplacement I/O PCI ou 16 emplacement HOT SWAP CPCI ou une combinaison des 2 Support jusqu'à 4 domaines Périphériques d’entrés sorties : Les serveurs MidFrame Supportent des périphériques d’entrés sorties de type PCI et/ou CPCI. Les cartes Cpci incluent un bus industriel à haute performance basé sur des spécifications électriques du standard PCI. Dans l’implémentation des Sun Fire MidFrame les cartes Cpci sont remplaçables à chaud tandis que les cartes PCI ne le sont pas. Mécanisme RAS ( reliabilty, availabity, servicabilty) avancés : Tous les serveurs Midframe fournissent de la haute disponibilité : Redondance matérielle Redondance de l’horloge système Détection de panne améliorée [POST] sur tous les circuits intégrés Maintenance en Ligne (Composant Hot Plug) Support Cluster Mise à jour dynamique des CPU et de la mémoire (DR) Vue de l’ensemble de l’architecture des Sun Fire MidFrame : Application Application Application Application OS Solaris OS Solaris OS Solaris OS Solaris OpenBoot Prom OpenBoot Prom OpenBoot Prom OpenBoot Prom Domaine A Domaine B Domaine C Plate-forme Shell (Système contrôleur) Matériel de la Plate-forme Domaine D Les systèmes contrôleur : Le SC primaire contient l’horloge du serveur ainsi que la logique du contrôle du serveur et de la surveillance. Il existe 2 modèles de SC : Une version pour les 3800 et l’autre version pour les 4800, 6800. Sur le plan électrique ils sont identiques à part quelques différences mineures concernant l’alimentation DC-DC ainsi qu’un ventilateur supplémentaire sur le SC du 3800 Les serveurs Sun Fire MidFrame utilisent une structure de bus de maintenance global pour surveiller l’environnement de la plateforme. Cette structure de contrôle est sous contrôle du System contrôleur et utilise une architecture de type bu appelé I2C. Le bus I2C surveille les éléments suivants : L’alimentation des serveurs La température La vitesse des ventilateurs Le SC secondaire à un rôle de redondance pour l’horloge système au cas où le SC primaire tomberai en panne. Distribution du Courrant : Tous les SunFire MidFrame installé dans un cabinet sont équipés de RTU. Cette RTU contient 2 RTS. Chaque RTS doit être connecté à une source d’alimentation de courrant séparée. Depuis la boite d’entré AC le courrant s’achemine vers le convertisseur AC-DC à travers le centre plane d’alimentation. Le courrant DC des serveurs Sun Fire MidFrame est organisé en grille de courrant (Power Grids). Chaque grille de courrant gère des emplacements de cartes spécifiques. Les serveurs 3800, 4800, 4810 on une seul grille de courrant GRID0. Le serveur SunFire 6800 supporte 2 grilles de courrant GRID0 et GRID1 Attribution des emplacements sur la grille de courrant : Serveur Sun Fire 3800 Sun Fire 4800 Sun Fire 4810 Sun Fire 6800 Sun Fire 6800 Grille de Courrant 0 0 0 0 1 Emplacements SB0, SB2, IB6, IB8 SB0, SB2, SB4, IB6, IB8, RP0,RP2 SB0, SB2, SB4, IB6, IB8, RP0,RP2 SB0, SB2, SB4, IB6, IB8, RP0,RP1 SB1, SB3, SB5, IB7, IB9, RP2,RP3 Les serveurs Sun Fire MidFrame offre des unités d’alimentation HOT SWAP et redondantes. Les unités d’alimentations sont interchangeables entre les 4800 et 6800. Tiroirs de ventilation : Tous les systèmes possèdent des tiroirs de ventilation qui fournissent un refroidissement redondant si un tiroir tombe en panne. Le Périphérique de stockage D240 : Nom de code : Wally Il supporte 2 disques UltraWide SCSI 3 de 18.2 GB Il supporte 1 lecteur DVD Il supporte 1 lecteur de bande DAT 4mm UltraWide SCSI 3 Configuration : Vous pouvez configurer le D240 en Full Bus ou en Split Bus. Un commutateur coulissant permettant de passer de l’une à l’autre configuration. A) Configuration Full Bus : Tous les lecteurs internes sont connectés à un seul domaine à l’aide d’une seul chaîne SCSI. B) Configuration Split Bus : Les lecteurs internes du D240 sont partagés en 2 bus. Chaque Bus se connecte à un adapter SCSI différent. Chaque adapter dans 1 domaine. Les Systèmes contrôleur : Sur les systèmes contrôleur ou SC ou encore SSC « System service contrôler » tourne un mini OS qui s’appel Vxworks ou Rtos et une application SCAPP qui va nous permettre de créer des domaines, partitionner la plateforme …… CONFIGURATION ET GESTION DE LA PLATEFORME : Une fois tous les éléments identifiés et allumées passons à la configuration de la plateforme : Pour initialiser une plateforme il faut tout d’abord se connecter en plateforme SHELL et lancer la commande setupplatform Une fois la configuration de la plateforme effectué régler le TOD de la plateforme avec la commande setdate, pour la France le fuseau horaire est ECT. Capacity-on-Demand : Le dispositif COD est contrôlé par un logiciel résident sur le SC. Il fournit les licences CPU et mémoire pour les serveurs MidFrame. Note : Si le système n’a pas été acheté en tant que système COD, les commandes COD seront désactivées à l’usine. Les serveurs COD, sont les serveurs livrés avec une capacité de CPU et de mémoire additionnelle mais non activés. Cependant vous pouvez rajouter les licences avec les commandes addcodlicense, mais également voir le statut des licences avec la commande showcodusage Alimentations et Mises hors tension des composants système : PLATEFORME Sun Fire 3800 Sun Fire 4800 Sun Fire 4810 Sun Fire 6800 Numéros de carte SB0, SB2, IB6, IB8, PS0, PS1, PS2, FT0, FT1, FT2, FT3, GRID0, all SB0, SB2, SB4, IB6, IB8, RP0, RP2, PS0, PS1, PS2, FT0, FT1, FT2, GRID0, all SB0, SB2, SB4, IB6, IB8, RP0, RP2, PS0, PS1, PS2, FT0, FT1, FT2, GRID0, all SB0, SB1, SB2, SB3, SB4, SB5, IB6, IB7, IB8, IB9, RP0, RP1, RP2, RP3, PS0, PS1, PS2, PS3, PS4, PS5, FT0, FT1, FT2, FT3, GRID0, GRID1, all Example: SC> poweron all SC > poweroff all Segment et domaines: Vous pouvez diviser votre serveur en plusieurs segments ou partition et en domaines. Les 2 termes sont employés pour désigner un moyen de diviser un seul système physique en plusieurs systèmes qui sont logiquement indépendants les uns les autres, chacun exécutant son propre environnement d’exploitation Solaris. Segments : Le terme segment ou partition se rapporte à une partie ou à l’ensemble de l’interconnexion Sun FirePlane. Le fait de mettre la plateforme en mode double-partition divise l’interconnexion Sun FirePlane en 2 systèmes cohérents indépendant ; Lorsqu’une plateforme est divisé en 2 segments, les cartes commutateurs Sun FirePlane (Répéteurs) sont divisées entre les 2 segments ce qui fait que la plateforme se confirme comme si chaque système était physiquement séparé. Toutes les connexions entres les cartes d’un segment et les cartes de l’autre segment sont désactivées. Les serveurs supportent jusqu'à 2 segments. Domaines : Les segments peuvent être divisés en plusieurs parties appelées domaines. Chaque domaine exécute sa propre instance Solaris et s’occupe de sa propre charge. Il n’y a pas d’interaction entre les domaines. L’avantage de la segmentation est de pouvoir augmenter le nombre de domaines ; Maximum 2 domaines par segment Démarrage et arrêt d’un domaine : Pour démarrer un domaine il faut exécuter la command setkeyswitch on Pour arrêter un domaine il faut exécuter la commande setkeyswitch off Le mode standby : Un domaine en mode standby n’est pas initialisé lors de la mise sous tension du système, mais les cartes elles sont mises sous tensions. Le mode secure : Identique à ON sauf que les commandes break, xir, reset ne sont pas reconnus Liste des composants disponibles du domaine « ACL » : L’ACL restreint les requêtes testboard, addboard, deleteboard à des cartes spécifiques/ Configuration des ACLS pour chaque domaine en tapant setupplatform –p acls Utiliser –r avec le nom des cartes pour enlever la carte de la liste. Utiliser –a avec le nom des cartes pour ajouter la carte dans la liste. En tapant uniquement – vous enlever toutes les cartes En tapant uniquement + vous ajouter toutes les cartes Pour connaître les acls taper showplatform –p acls Codages des périphériques physiques des serveurs Sun Fire Midframe : Codage d’une carte système : Exemple : /ssm@0,0/SUNW,UltraSPARC-III@b,0 CPU offset CPU AID Vous pouvez calculer une AID / CPU de la façon suivante : 1) b (hex) = 11 (dec) = 01011 (bin) En prennant les informations en binaires : 01011 : Les 3 bits (010) du poids le plus fort représentent le numéro de ma carte SB en l’occurrence 2. Les 2 bits du poids le plus (11) faible représentent le numéro du proc de la carte en l’occurrence 3. Donc cela nous donne le processeur 3 de la carte système 2. Ou par une autre façon : 2) Diviser l’AID par 4 « l e nombre de CPU » 11/4=2 reste 3 donc SB 2 CPU 3 Codage d’une carte IO : Ex : /ssm@0,0/pci@19,700000/pci@3/SUNW,isptwo@4/sd@5,0 Node ID Bus Offset PCI Controller Schizo AID Device Number Device Instance Node ID: Toujours 0 pour les Sun Fire Schizo ID : Determine la carte d’I/O et le controller Schizo Bus offset: Bus Pci A ou B Device Number: L’adresse du périphérique au niveau du bus Pci controller : Détermine quelle carte est utlisé dans un slot Device instance : identifie le périphérique dans le kernel AID schizo : Selon le modèle il peut y avoir jusqu'à 4 cartes I/O sur une plateforme SunFire Midframe chacune arbitrant 2 contrôleurs Schizo. Pour calculer L’AID schizo il existe également 2 façons : 1) convertir le Schizo AID en binaire et appliquer la même règle qu’aux cartes systèmes Ex : 19 (Hex) = 11001 (bin) Les 3 bits (110) du poids le plus fort représentent le numéro de ma carte IO en l’occurrence 6. Les 2 bits du poids le plus (01) faible représentent le schizo de la carte en l’occurrence 1. 2) Divisant l’AID schizo par 2 et soustraire de 6 ex : 19(Hex)=25(Dec) 25/2 -6= 6 reste 1 Resultat : IO Board 6 shcizo 1 IPMP (IP Multipathing) : IPMP fournit à Solaris un mécanisme de redondance réseau qui évite les SPOF. IPMP supporte uniquement les interfaces de même type dans groupe multipath ex (Eth, Token). Si le Multipath est utilisé la variable d’environnement local-mac-address doit être égal a TRUE. Le daemon /sbin/in.mpathd est responsable de la gestion du multipathing au niveau réseau, il est lancé par ifconfig lorsque l’option group est détectée. Ne lancer pas plusieurs instances Note : Fichier de configuration de in.mpathd est /etc/default/mpathd IPMP : Actif /Standby Configuration : # cat /etc/hostname.hme0 192.168.10.215 group test up # Cette adresse est celle de l’interface hme0 addif 192.168.10.216 –failover deprecated up # IP address de l’interface essai hme0:1 addif 192.168.10.250 up # Interface logique complémentaire # cat /etc/ hostname.hme1 192.168.10.217 group test deprecated –failover standby up # interface standby Reconfiguration dynamique: La reconfiguration dynamique est la capacité de modifier la configuration d’un domaine en mettant des composants en ligne ou hors ligne sans interrompre le domaine ni le rebooter. La DR est utile si une carte doit être rajouté voir remplacé. Avant de changer quoique ce soit il faut s’assurer que les périphériques sont suspend-safe Cela veut dire qu’il n’accède pas à la mémoire et qui n’interrompt pas le système pendant que l’OS est en repos (Quiesced). Dans la gamme Sun Fire Midframe les cartes SB et IO qualifiés par Sun sont suspendsafe. Lorsqu’on déconnecte une SB dont la mémoire est non-paginable (permanente), l’OS est brièvement arrêté ce qui s’appel le mode (Quiescence). Toute l’activité du système est arrêté pendant quelque secondes (1min). Vous pouvez déterminer si la carte contient la mémoire permanente en éxecutant la commande cfgadm –av Ex : La carte peut contenir le Kernel de l’OS en mémoire. Matériel Hot_Plug : Avant de retirer toute cartes, vérifier bien que la LED enlèvement OK est bien allumé. Entrelacement mémoire : La DR ne fonctionne pas si la mémoire est entrelacée entre les cartes systèmes. Il faut donc positionner la valeur interleave-scope = within-board en configurant le domaine Voir (setupdomain). NOTE : Lorsque vous remplacer une nouvelle carte IO dans un domaine opérationnel, la nouvelle carte IO n’est pas testée automatiquement. Les essais nécessite un CPU et de la mémoire privé. Dans un domaine opérationnel tous les composant sont utilisés par l’OS. Si la carte n’a pas été testée auparavant il est possible qu’une carte IO défectueuse fasse tomber le système lors de l’initialisation. Un domaine de test doit être créer afin de pouvoir tester la nouvelle carte Les tâches de reconfiguration dynamique sont effectuées à l’aide de la commande cfgadm MPXIO ou (Sun Storedge traffic manager): Mpxio ets completement intégrer au cœur même de Solaris, il contribue à protéger les défaillences des E/S dues aux pannes controleur I/O. Il augmente les performances en équilibrant la charge à travers de multiples canaux I/O. Il supporte la DR. MPXIO à besoin de la version Solaris 8 update 7 ou 02/02. Le fichier de configuration MPXIO se trouve dans /kernel/drv/scsi_vhci.conf mpxio-disable=no Type de redondance: Disks Auto Failover Manual Switchover Load Balancing Kernel/ Package Networks Auto Failover Manual Switchover Load Balancing Kernel Alternate Veritas Pathing DMP (Old Version) Y Y Y Y N Y Package Package N Y N N NAFO Sun Trunking IPMP MPXIO Y Y Y Kernel Y Y (SC3.0) N Package Y N Y Package Y Y (FailBack) 802.3ad Kernel