Keep pool space under 80% utilization to maintain pool performance.

[...]

If the primary workload is immutable files (write once, never remove), then you can keep a pool in the 95-96% utilization range.

Le 95-96% correspond au changement de block allocation contrôlé par le paramètre metaslab_df_alloc_threshold :

The minimum free space, in percent, which must be available in a space map to continue allocations in a first-fit fashion. Once the space_map’s free space drops below this level we dynamically switch to using best-fit allocations.

Vous l’aurez compris, le monitoring des zpool est primordiale. Sous Nexenta ce n’est pas chose facile car seuls les point de montage sont visibles par défaut en snmp, mais nous avons une solution simple n’impliquant que peux de modifications.

• ajouter les lignes suivantes dans votre conf snmp :

extend .1.3.6.1.4.1.2021.87 zpool_name /bin/bash -c “zpool list -H -o name”
extend .1.3.6.1.4.1.2021.87 zpool_capacity /bin/bash -c “zpool list -H -o capacity”

• copier le fichier zpool_capacity.xml dans le répertoire /resource/snmp_queries de votre cacti
• importer les templates cacti_data_query_zfs_-_zpool_capacity.xml et cacti_graph_template_zfs_-_zpool_capacity.xml dans l’interface web cacti
• choisissez les zpool à monitorer sur votre/vos nexenta (y compris le syspool)

• en option, créez un Threshold Template pour recevoir une alerte en cas de dépassement de 80%

zpool capacity

Les premiers chapitres détaillent l’offre vSphere 5 et comment bien intégrer cette technologie dans le Datacenter avec des recommandations et préconisations tirées des expériences complémentaires des deux auteurs. Les chapitres suivants sont plus pratiques avec un retour d’expérience détaillé traitant de la mise en place d’un projet en quatre grandes phases.

La préface est signé Chad “storage” Sakac que vous connaissez tous via son blog Virtual Geek et Eric a amicalement cité Hypervisor.fr dans ses références.

Pour ceux que ça intéresse, la version électronique semble être offerte pour toute acquisition de la version papier.

]]> http://www.hypervisor.fr/?feed=rss2&p=3557 0 http://www.hypervisor.fr/?p=3328 http://www.hypervisor.fr/?p=3328#comments Tue, 27 Sep 2011 15:19:09 +0000 NiTRo http://www.hypervisor.fr/?p=3328 En vue d’une maintenance réseau, vous pourrez être amené à désactiver la fonction HostMonitoring d’HA comme le recommande VMware :

When making changes to the networks that your clustered ESX/ESXi hosts are on, VMware recommends that you suspend the Host Monitoring feature.

Nous vous recommandons pour cela notre petit OneLiner PowerCLI maison :

Get-View -ViewType ClusterComputeResource|%{$_.ReconfigureComputeResource_Task((New-Object VMware.Vim.ClusterConfigSpecEx -Property @{DasConfig=(New-Object VMware.Vim.ClusterDasConfigInfo -Property @{HostMonitoring="disabled"})}), $true)}

Vous trouverez facilement la commande inverse

• The esxupdate utility is for ESX only
• VMware Tools must be installed for hotplug functionality to work properly
• You can grow the extent up to 2 TB
• The vpxuser is used for vCenter Server permissions.
• The esxtop utility reads its default configuration from .esxtop4rc

A lire d’urgence.

]]> http://www.hypervisor.fr/?feed=rss2&p=1043 5 http://www.hypervisor.fr/?p=816 http://www.hypervisor.fr/?p=816#comments Mon, 08 Jun 2009 23:56:05 +0000 NiTRo http://www.hypervisor.fr/?p=816 MAJ 05/12/2009 : “vSwitch pour les nuls” est maintenant disponible en pdf !

Ken Cline, un membre reconnu de la communauté et depuis peu Senior Consultant chez VMware, a bouclé il y a quelques jours son “Great vSwitch Debate”. Tout a commencé sur le forum VMware et a fini sur son blog par un énorme article en 8 parties.

Il est question d’à peu près tout ce qu’un admin VMware doit savoir sur le fonctionnement d’un vSwitch et des config optimales en fonction du nombre de cartes réseau physiques disponibles.

La partie 3 est particulièrement intéressante techniquement car Ken détaile les différentes méthodes de load-balancing. On y apprend, par exemple, l’utilisation des ports d’un vSwitch en fonction de la séquence de démarrage des vm :

Incontournable pour n’importe quel vAdmin…

Ces proxy, comme d’autres également, scannent (anti-virus, anti-trojants) les fichiers téléchargés avant de les transmettre aux clients. Lorsque le fichier ne fait que quelques Ko c’est presque transparent mais lorsqu’il fait quelques dizaines de Mo c’est plus long. Aucun problème lorsque la requête est faite par un navigateur car le proxy redirige vers une page d’attente affichant la progression du download. Mais lorsque la requête provient d’un composant tel qu’Update Manager c’est le timeout assuré.

Résultat, Update Manager ayant téléchargé le fichier xml contenant la liste des nouvelles mises à jour mais le download des updates ayant échoué, vous vous retrouvez avec la liste des MAJ qui n’existent pas dans le répository et que vous ne pouvez donc pas appliquer. Malheureusement, impossible de forcer un nouveau download et télécharger les updates manuellement pour les copier ensuite dans le repository relèverait de la torture.

Après quelques recherches et un peu d’improvisation dans la base SQL VIM_UMDB, nous avons trouvé 2 solutions. L’une figure dans l’admin guide d’Update Manager et l’autre très certainement pas supporté du tout par VMware puisqu’il s’agit de modifier le contenu d’une table de la base SQL.

VMware a en effet prévu que le VirtualCenter ne soit pas connecté à Internet. Il existe donc un autre composant sur le CD d’install : UMDS aka Update Manager Download Service.

Une fois ce composant installé sur un serveur en DMZ ou ayant un accès direct à Internet, il suffit de configurer (en CLI uniquement) UMDS avant de lancer un téléchargement des updates. Vous pouvez utiliser des commandes pour ne télécharger que les updates sur une période précise et forcer un nouveau téléchargement en cas d’échec. Une fois le téléchargement terminé, il suffit d’utiliser une commande pour exporter le contenu du repository de l’UMDS vers un répertoire et d’utiliser une autre commande sur le VirtualCenter pour les importer. Toutes ces commandes sont détaillées à la page 16 de l’admin guide.

L’autre solution, plus “trash”, consiste à supprimer de la base SQL VIM_UMDB (présente sur le VirtualCenter) les updates dont le download aurait échoué.

Il suffit pour cela d’installer Management Studio Express de Microsoft sur le VirtualCenter et de vous connecter à la base SQL de ce dernier.

Une fois la table dbo.VCI_UPDATES identifiée, il faudra dans un premier temps désactiver les relations avec les autres tables pour pouvoir ensuite supprimer les lignes des updates à re-télécharger.

Il faut ensuite relancer le service vmware-ufad-vci et la tache planifiée de l’Update Manager. La ou les MAJ seront alors re-téléchargée(s).

Nous avons testé à plusieurs reprise cette métode et bien qu’aucun effet indésirable ne se soit manifesté, nous vous recommandons vivement de faire un backup avant toute modification de la base.

Pour ceux qui veulent se faire du mal, suivez le link.

Pour les autres, sachez qu’avec le software initiator il n’est pas possible de faire du load balancing vers une seule et même target iscsi . Utilisez plusieurs target si vous souhaitez exploiter tout le potentiel de vos NIC. Ou attendez ESX 4…

En suivant une discussion sur le blog de Duncan Epping (Senior PSO Consultant chez VMware) concernant le design d’un cluster HA répartie sur 2 châssis de lames, nous somme tombés sur un post détaillant le fonctionnement précis de VMware High Availability (HA). Duncan nous a autorisé à le traduire.

Avec les dernières version d’ESX 3.5 & VirtualCenter 2.5, un cluster HA peut contenir 32 nœuds maximum. Contrairement à un cluster XenServer (par exemple…), les différents noeuds d’un cluster HA n’ont pas besoin d’un quorum pour communiquer entre eux. Cet avantage, on le paye forcement d’un inconvénient…

En fait, les nœuds d’un cluster HA ne communiquent pas totalement entre eux : Les 5 premiers (tant qu’ils restent online) serveurs  ajoutés au cluster (primary nodes) se communiquent, via le réseau, les réglages du cluster, leurs état et l’état des autres serveurs (secondary nodes). Les autres serveurs (1 à 27) communiquent leur état aux primary nodes. Tout cela chaque seconde (valeur par défaut, modifiable via l’option das.failuredetectioninterval).

L’un des 5 primary nodes assume le rôle de fail-over coordinator qui coordonnera le redémarrage des vm d’un ou des nœuds HS. Les VM sont redémarrées dans l’ordre où elles ont été coupées (priorité prise en compte).

Malheureusement, un nœud primaire n’est re-promu que si le nœud HS est placé en maintenance mode ou retiré du cluster. Par conséquent, si les 5 nœuds primaires “tombent” aucune vm ne sera redémarrée car aucun  fail-over coordinator ne sera disponible pour gerer cette action.

C’est pour cette raison qu’il est impossible de fixer la tolérance du cluster à plus de 4 nœuds :

Conséquence : En considerant un cluster de 32 nœuds répartis sur 2 châssis (16+16), il est probable que les 5 primary nodes soient dans le même châssis.

le fichier /var/log/vmware/aam/aam_config_util_listnodes.log contient la liste des nœuds et leur type (primary ou secondary) :

La ré-élection d’un primary node étant aléatoire, jouer avec le maintenance mode risque de vous faire perdre la tête, même si c’est la seule solution pour forcer un changement de type.

Ducan suggère une alternative plus sûre qui consiste à créer de plus petit clusters (dans notre cas, 4x 8 nœuds) et de les répartir sur les 2 châssis. Le but étant de diminuer la probabilité que plus de 4 nœuds “tombent” simultanément.

ESX 4 nous fera peut etre grace d’une alternative plus techniquement correct…

Malheureusement, les partitions “data” ne sont pas toujours les seules à subir un nombre important d’I/O. Les environnements Terminal Serveur et Citrix en sont un parfait exemple lorsqu’il s’agit des profils utilisateurs.

Alors qu’avec VMFS2 il était nécessaire de passer par la case “ligne de commande”, une partition VMFS3 créée (pas migrée) via le client VI est désormais bien alignée à la structure de la LUN. De même sous Windows 2008, une partition est par défaut correctement alignée à la structure du disque).

Mais sous Windows (2003 et 2000 s’il en reste ?!) bien qu’il soit facile d’aligner une partition data (MBR ou GPT) lors de sa création ou une futur partition système (avec des outils tel que GParted via une iso bootable), il est nettement plus difficile de le faire sur une partition existante.

Au détour d’une conversation sur le forum VMware datant de février 2007, un membre donne une solution aussi efficace que complexe :

La technique consiste à déplacer la partition sur un disque temporaire et de la recopier sur la partition d’origine avec un paramètre d’alignement. Pour gagner du temps, nous avons tester la procédure en copiant directement la partition sur un disque qui remplacera le disque d’origine. Démonstration :

• Télécharger l’iso de DFSee
• Faire un backup de la VM
• Créer un disque secondaire sur la VM, plus grand d’1Mo que l’original et booter sur l’iso
• Une fois dans l’application, appuyer sur Echap pour passer en mode ligne de commande :

• taper la commande “disk 1″ puis “part 1″ :

• taper la commande “move -f:2 -e:0×41,s -c” pour copier la partition sur le 2eme disque avec le bon alignement :

• Sortir de DFSee (F3) et relancer (dfseerun 1)
• Toujours en ligne de commande, sélectionner la partition 1 du disque 2 (“disk 2″ puis “part 1″)
• taper la commande “fixpbr” :

• Rebooter sur le bon disque et taper la commande suivante sous windows : “wmic partition get BlockSize, StartingOffset, Name, Index”. Le StartingOffset est passé à 65536.

Dans le screenshot suivant, la 1ere partition du disque 1 est aligné avec la méthode ci dessus (StartingOffset à 65536). Dans l’ordre nous avons créé une partition non alignée (StartingOffset à 32256) que nous avons supprimé et recréé avec le paramètre “align=64″. Les deux méthodes aboutissent bien au même résultat :

Merci encore à embo500 du forum VMware.

Ce document rédigé par Seva Semouchinun, TAM (Technical Account manager) pour VMware Allemagne, ne peut etre considéré comme document officiel mais plutot comme une sorte de “community white paper” comme on peut en trouver sur le site de VMware.

La version définitve de ce documents sera posté sur VI:OPS.