OmniCube: Guide des opérations

OmniCube: Guide des opérations

EFit-partners

Mars 2026

Chapter 1
Réseau

1.1  Configuration réseau des nodes

1.1.1  LACP et MLAG

Pour chaque node, il est recommandé d'utiliser une agrégation (LACP ou Link Aggregation Control Protocol) de deux ports d'au moins 10 Gb/s pour le connecter aux équipements d'infrastructure via en général un ou plusieurs core switches. Cette configuration permet assez simplement d'accroître: 
~$ dladm show-aggr -L aggr0
LINK        PORT         AGGREGATABLE SYNC COLL DIST DEFAULTED EXPIRED
aggr0       bnxe0        yes          yes  yes  yes  no        no
--          bnxe1        yes          yes  yes  yes  no        no
La configuration d'un aggrégat LACP permet de choisir une politique de sélection des ports à utiliser pour répartir la charge du trafic sortant. Les politiques possibles sont les suivantes:
L2
Sélectionne le port ethernet sortant en fonction des adresses MAC source et destination du paquet.
L3
Sélectionne le port sortant en fonction des adresses IP source et destination du paquet.
L4
Sélectionne le port sortant en fonction des informations de protocole de couche supérieure contenues dans le paquet. Pour TCP et UDP, cela inclut les ports source et destination.
~$ dladm show-aggr -P
LINK            POLICY   ADDRPOLICY           LACPACTIVITY  LACPTIMER   FLAGS
aggr0           L2,L3    auto                 active        short       -----
Côté core switches, il est possible d'utiliser le protocole MLAG (Multi-chassis Link Aggregation Group) pour permettre à la moitié des liens du LACP de se terminer sur un switch et l'autre moitié sur un autre. C'est ce protocole qui assure que la défaillance d'un des deux core switches soit transparente pour les nodes.

1.1.2  VLAN

La ségrégation des trafics réseaux en VLANs est une des clés de la sécurité d'une infrastructure ICT. Les VLANs peuvent être utilisés tant au niveau des nodes qu'au niveau des machines virtuelles.
Il est avisé de configurer les nodes dans un VLAN de gestion séparé du reste de l'infrastructure. Cette configuration se présente sous d'une VNIC avec VLAN ID. Cette VNIC peut alors se voir attribuer une adresse IP. 
~$ dladm show-vnic mgt100
LINK         OVER       SPEED    MACADDRESS        MACADDRTYPE VID  ZONE
mgt100       aggr0      10000    2:8:20:f6:11:2d   random      100  --
~$ ipadm show-addr mgt100/v4
ADDROBJ           TYPE     STATE        ADDR
mgt100/v4         static   ok           10.255.255.11/24

Chapter 2
SAN (Storage Area Network)

2.1  Disques physiques

L'Hypercube n'a pas de limitation spécifique quant aux types de disques physiques supportés. Sous réserve que le matériel soit reconnu1 par OmniOS, les disques suivants peuvent être utilisés:
Suivant les besoins, les disques peuvent être configurés dans un ou plusieurs zpool qui seront alors utilisés comme stockage de masse pour les machines virtuelles. 
~$ zpool status sr01efit
  pool: sr01efit
 state: ONLINE
  scan: scrub repaired 0B in 1 days 06:47:48 with 0 errors on Wed Apr 23 12:55:02 2025
config:

        NAME                         STATE     READ WRITE CKSUM
        sr01efit                     ONLINE       0     0     0
          mirror-0                   ONLINE       0     0     0
            c0t5000C500C7DDD013d0    ONLINE       0     0     0
            c0t5000C500C8224F99d0    ONLINE       0     0     0
          mirror-3                   ONLINE       0     0     0
            c0t5000C500D676914Cd0    ONLINE       0     0     0
            c0t5000C500D6763B04d0    ONLINE       0     0     0
        logs    
          mirror-4                   ONLINE       0     0     0
            c1t0024CF0130001D8Bd0s3  ONLINE       0     0     0
            c5t0024CF0130001D7Cd0s3  ONLINE       0     0     0

errors: No known data errors

2.2  Volumes / zvol

Les volumes, appelés zvol dans la nomenclature ZFS, sont essentiellement utilisés comme raw disks pour la virtualisation. Il s'agit de block devices configuré au-dessus de ZFS. Les zvols permettent de profiter de toute les fonctionnalités de ZFS, en particulier pour les configurations RAID.
Les zvols sont les volumes de base du SAN de l'Hypercube.
Pour augmenter la taille d'un zvol ZFS, utilisez la commande suivante: 
~# zfs set volsize=new_size nom_du_pool/nom_du_zvol
Il faut toutefois veiller à ce que la nouvelle taille soit supérieure à la taille actuelle. Assurez-vous que votre zpool dispose de suffisamment d'espace libre avant d'effectuer cette opération.

2.3  Zpool

2.3.1  Mirroring

Le mirroring permet de garantir que toute écriture sur le stockage de données est toujours dupliquée sur au moins deux disques physiques. En cas de panne d'un disque, le RPO est toujours de zéro. Le mirroring élimine le disque de la liste des single points of failure (SPOF).
Il faut noter que le mirroring utilisé par l'Hypercube est software. Il s'affranchit donc d'un contrôleur RAID dont la défaillance implique son remplacement par le même modèle, souvent avec la même version du firmware2.
Cette remarque s'applique même lorsque les disques utilisés proviennent de baies de stockages via un SAN Fibre Channel, FCoE ou iSCSI. Bien que l'utilisation du mirroring hardware soit supportée, elle n'est pas recommandée.

2.3.2  Mirroring cross-nodes

Au delà d'un ßimple" mirroring qui protège les données de la défaillance d'un disque, l'Hypercube permet le mirroring entre deux ou trois nodes.

2.4  Tiering

L'Hypercube gère le stockage hiérarchisé des données ou tiering.
Le tiering est une méthode permettant d'affecter différentes catégories de données à divers types de supports de stockage afin de réduire les coûts globaux de stockage et d'améliorer la performance et la disponibilité des applications critiques. Il s'agit en pratique de classer les données en fonction des performances d'accès voulues ce qui correspond le plus souvent à leur fréquence d'accès par les utilisateurs et les applications. Les données sont ensuite affectées à des types de stockage spécifiques.
Il en résulte des niveaux de stockage dont les caractéristiques de capacité, de coût et de performance varient, ce qui permet de répondre à des besoins de stockage différents au sein d'un même Hypercube.
L'Hypercube gère les disques
Une même machine virtuelle peut donc se voir attribuer des disques de différents types en fonction des performances et coûts attendus.
Enfin, une partie de la RAM est utilisée par ZFS comme cache disque en lecture uniquement ce qui n'en fait donc pas un niveau de stockage à proprement parler même si cela participe grandement à la performance générale de l'Hypercube. Cette fonctionnalité est configurable par modification du paramètre zfs:zfs_arc_max dans le fichier /etc/system.d/_omnios system defaults.

2.5  Snapshots

ZFS, le file system utilisé, permet de prendre à intervalles réguliers des snapshots. Un snapshot peut être vu comme une "photographie" statique des données à un moment donné. Les snapshots peuvent être créés très rapidement et ne consomment initialement aucun espace supplémentaire dans le zpool.
En cas de problèmes tels une destruction de données, intentionnelle ou non, ou un crypto-virus, il est possible de retourner à l'état des données correspondant à un snapshot.
Les snapshots peuvent bien entendu être pris "à chaud", c'est à dire lorsque la machine virtuelle correspondante tourne. De plus, un snapshot n'ayant aucun impact mesurable sur les performances générales du système, il n'y a pas de limite quant à leur nombre.
La politique proposée par défaut est de conserver un snapshot toutes les heures pendant les dernières 24 heures, un tous les jours pendant les six derniers jours et un toute les semaines aussi longtemps que nécessaire. En cas de problèmes tels que mentionnés ci-avant, le RPO est donc d'une heure, tout ceci restant configurable.
La configuration proposée est appliquée à tous les volumes y compris ceux fournis aux machines virtuelles, quel que soit leur type. L'Hypercube dispose donc d'une machine à remonter le temps par pas d'une heure qui lui permet d'offrir une certaine immunité face aux crypto-virus par exemple.
Pour remonter le temps, il existe deux façons de procéder:
  1. le rollback
  2. le clone

2.5.1  Configuration de la politique de snapshot

La politique des snapshots et backups est basée sur des propriétés personnalisées des zfs hébergeant les zones.
Actuellement quatre propriétés sont utilisées:
hc:snapshotting
Si défini à yes, des snapshots seront créés.
hc:snappolicy
Nom de la politique de snapshots associé à la zone.
hc:remotebackup
Si défini à yes, des snapshots seront envoyés vers le serveur de backup.
hc:insync
La valeur yes indique que le snapshot a été envoyé vers le serveur de backup.
La manière dont les snapshots sont gérés est définie dans les différentes politiques de backup localisées ici:
La structure d'une politique est définie comme suit: 
# Déclaration d'une Array en bash
declare -A RETENTION
# Nombre de snapshots annuels gardés sur le zfs de la zone
# FORMAT: @yearly-[yy] derniers 2 chiffres de l'année
RETENTION[yearly]=0
# Nombre de snapshots hebdomadaires gardés sur le zfs de la zone
# FORMAT: @weekly-[yy]-[WW] Numéro de semaine absolu
RETENTION[weekly]=0
# Nombre de snapshots journaliers gardés sur le zfs de la zone
# FORMAT: @daily-[yy]-[WW]-[DD] Jour de la semaine, dimanche étant 1
RETENTION[daily]=0
# Nombre de snapshots horaires gardés sur le zfs de la zone
# FORMAT: @hourly-[yy]-[WW]-[DD]-[HH] Heure de la journée de 24 Hrs
RETENTION[hourly]=72
# Config utilisés pour le backups des ZFS sur disques
# Nombre de backups (full + incremental envoyés sur disque) pour le type de backup spécifié
RETENTION[backup-weekly]=5
# Heure à laquelle se fait le type de backup spécifié
RETENTION[backup-weekly-time]=3
# Jour auquel se fait le type de backup spécifié
RETENTION[backup-weekly-day]=7
# Le zfs du serveur de backup est-il encrypté
IS_ENCRYPT=0
# SSH user utilisé pour envoyé les snapshots vers le serveur de backup
# Par sécurité, il est préférable de lui limiter l'accès sur le ZFS du serveur de backup en ne lui autorisant que les permissions
# suivantes sur ce ZFS: create,mount,receive,encryption
# zfs allow %%USER%% create,mount,receive,encryption %%BACKUP_SRV_ZFS%%
BKPUSER=%%USER%%
# IP du serveur de backup. La connexion au serveur de backup devra être automatique (clé ssh ou autre)
BKPHOST=%%BACKUP_SRV_IP%%
# ZFS root pour tous les backups
BKPDS=%%BACKUP_SRV_ZFS%%
La gestion globale est snapshots est prise en charge par quatre scripts:
/opt/omnicube/backup/autosync
: création des snapshots
/opt/omnicube/backup/autocleansnap
: suppression des snapshots
/opt/omnicube/backup/autosync
: envoi des snapshots vers le serveur de backup
/opt/omnicube/sbin/check_zpool_capacity.sh
: vérification de la place disponible au sein des zpools (Pour raison de performance, il est préférable de ne pas dépasser 80% d'occupation des zpools)
Le tout est lancé par des crons 
~$ pfexec crontab -l
....
6  * * * * /opt/omnicube/backup/autosnap >/dev/null
26,46  * * * * /opt/omnicube/backup/autosync >/dev/null
20 3 * * * /opt/omnicube/sbin/zone_save.sh
36 * * * * /opt/omnicube/backup/autocleansnap >/dev/null
16 * * * * /opt/omnicube/sbin/check_zpool_capacity.sh > /dev/null

2.5.2  Opérations de bases sur les snapshots

Pour voir la liste de tous les snapshots disponibles pour une zone, il suffit de lancer la commande suivante sur le zpool de la zone 
~$ zfs list -t snapshot -r [ZONE]
Ce qui donne par exemple: 
~$ zfs list -t snapshot -r zonevm01
NAME                                                    USED  AVAIL     REFER  MOUNTPOINT
zonevm01/zones/zonevm01@INIT                        0B      -       24K  -
zonevm01/zones/zonevm01/root@hourly-26-08-28-11  20.0M      -     14.8G  -
zonevm01/zones/zonevm01/root@hourly-26-08-28-12  11.5M      -     14.8G  -
zonevm01/zones/zonevm01/root@hourly-26-08-28-13  10.2M      -     14.8G  -
zonevm01/zones/zonevm01/root@hourly-26-08-28-14  8.73M      -     14.8G  -
zonevm01/zones/zonevm01/root@hourly-26-08-28-15  8.56M      -     14.8G  -
zonevm01/zones/zonevm01/root@hourly-26-08-28-16  8.40M      -     14.8G  -
zonevm01/zones/zonevm01/root@hourly-26-08-28-17  8.71M      -     14.8G  -
zonevm01/zones/zonevm01/root@hourly-26-08-28-18  8.98M      -     14.8G  -
zonevm01/zones/zonevm01/root@hourly-26-08-28-19  8.67M      -     14.8G  -
zonevm01/zones/zonevm01/root@hourly-26-08-28-20  8.33M      -     14.8G  -
...
zonevm01/zones/zonevm01/root@hourly-26-09-03-07  8.98M      -     14.8G  -
zonevm01/zones/zonevm01/root@hourly-26-09-03-08  8.91M      -     14.8G  -
zonevm01/zones/zonevm01/root@hourly-26-09-03-09  8.56M      -     14.8G  -
zonevm01/zones/zonevm01/root@hourly-26-09-03-10  8.75M      -     14.8G  -
Dans la gestion quotidienne des snapshots, les propriétés les plus intéressantes sont les quatre propriétés personnalisées mentionnées ci-avant et les propriétés creation (en UTC), used et enfin clones qui permet de savoir si des clones dépendent de ce snapshot. 
~$ zfs get hc:snapshotting,hc:snappolicy,hc:remotebackup zonevm01/zones/zonevm01/root
NAME                                PROPERTY           VALUE              SOURCE
zonevm01/zones/zonevm01/root  hc:snapshotting  yes                local
zonevm01/zones/zonevm01/root  hc:snappolicy    production-daily   local
zonevm01/zones/zonevm01/root  hc:remotebackup  yes                local

~$ zfs get used,creation,clones,hc:insync zonevm01/zones/zonevm01/root@hourly-26-09-02-05
NAME                                                   PROPERTY     VALUE                  SOURCE
zonevm01/zones/zonevm01/root@hourly-26-09-02-05  used         8.40M                  -
zonevm01/zones/zonevm01/root@hourly-26-09-02-05  creation     Mon Mar  2  5:06 2026  -
zonevm01/zones/zonevm01/root@hourly-26-09-02-05  clones       -                      -
zonevm01/zones/zonevm01/root@hourly-26-09-02-05  hc:insync  yes                    local              -

~$ zfs get used,creation,clones,hc:insync zonevm01/zones/zonevm01/root@hourly-26-08-01-17
NAME                                                   PROPERTY     VALUE                                                                                               SOURCE
zonevm01/zones/zonevm01/root@hourly-26-08-01-17  used         8.01M                                                                                               -
zonevm01/zones/zonevm01/root@hourly-26-08-01-17  creation     Sun Mar  1 17:06 2026                                                                               -
zonevm01/zones/zonevm01/root@hourly-26-08-01-17  clones       zonevm01/zones/zonevm01/clone-26-08-01-17-02,zonevm01/zones/zonevm01/clone-26-08-01-17  -
zonevm01/zones/zonevm01/root@hourly-26-08-01-17  hc:insync  yes                                                                                                 local

2.5.3  Rollback

Avant toute opération qui nécessite des restores à partir de snapshot, il est impératif d'arrêter la zone.
Le zfs rollback ramène l'ensemble des données d'un dataset à un snapshot précédent. Lorsqu'un dataset est ramené en arrière, toutes les données qui ont été modifiées depuis le snapshot sont supprimées et le dataset revient à l'état dans lequel il se trouvait au moment du snapshot.
Le moyen le plus rapide de faire un rollback est de taper la commande suivante: 
~$ pfexec zfs rollback [ZFS]@[SNAP]
Par défaut, la commande refuse de revenir à un snapshot autre que le plus récent. Pour ce faire, tous les snapshots intermédiaires doivent être détruits en spécifiant l'option -r. 
~$ pfexec zfs rollback -r [ZFS]@[SNAP]
Si les snapshots plus récents contiennent des clones, il faudra aussi les détruire ce que l'option -R prend en charge: 
~$ pfexec zfs rollback -R [ZFS]@[SNAP]
Le problème de cette approche est qu'on détruit complètement l'historique et la finesse d'approche permise par l'utilisation de snapshots. Ce n'est donc à utiliser que si l'on est absolument certain que les snapshots plus récents ne contiennent aucune information potentiellement utile.
Pour éviter cette destruction pour, par exemple, permettre une analyse d'une attaque informatique, il faut privilégier l'utilisation de clones.

2.6  Clone

2.6.1  Généralités

Un clone est un volume ou un système de fichiers inscriptible dont le contenu initial est identique à celui d'un autre ensemble de données. Comme pour les snapshots, la création d'un clone est presque instantanée et ne consomme initialement aucun espace supplémentaire.
Les clones ne peuvent être créés qu'à partir d'un snapshot. Lorsqu'un snapshot est cloné, il crée une dépendance implicite entre le parent et l'enfant. Même si le clone est créé ailleurs dans la hiérarchie du jeu de données, le snapshot original ne peut pas être détruit tant qu'un clone existe. La propriété origin expose cette dépendance, et la commande destroy liste toutes les dépendances de ce type, si elles existent.
La relation de dépendance parent-enfant du clone peut être inversée à l'aide de la sous-commande promote. Le système de fichiers "d'origine" devient alors un clone du système de fichiers spécifié, ce qui permet de détruire le système de fichiers à partir duquel le clone a été créé.

2.6.2  Clone d'une zone

L'utilisation de clones permet de garder l'historique propre aux snapshots tout en émulant des rollbacks en démarrant la zone à partir du clone.
Prenons l'exemple précédent avec zonevm01.
Imaginons que nous voulions revenir à l'état de la zone au moment où le snapshot zonevm01/zones/zonevm01/root@hourly-26-09-03-07 a été pris. Faire un rollback impliquerait la destruction des snapshots postérieurs suivants:
Pour les préserver tout en gardant les même fonctionnalités, il suffit de faire les opérations suivantes:
Cette procédure peut se répéter pour plusieurs snapshots différents. Une fois la bonne version trouvée, il suffit de faire une copie des disques vers le zfs courant.
Cette procédure permet de garder l'historique des snapshots en local et sur le serveur de backup.
Il existe une procédure plus rapide mais qui demande une intervention sur le serveur de backup pour que les snapshots envoyés en remote fonctionnent toujours.

2.7  Backups

2.7.1  Généralités

Le système de backups de l'Hypercube se base sur des fonctionnalités propres à ZFS comme les snapshots et les propriétés personnalisées.
Il est intégré à l'Hypercube et ne demande pas de logiciels externes.
Lors de la création d'une zone par exemple, le premier snapshot de ses volumes sert de base au backup. Par la suite, seule la différence entre un nouveau snapshot et le précédent déjà copié est transmise au node qui héberge le backup. Ainsi le node hébergeant le backup possède, heure par heure, une copie complète des machines virtuelles.
Il faut noter que la distinction habituellement faite entre backup complet et backup différentiel disparaît puisque les snapshots transmis sont äppliqués" au backup et non simplement stockés séparément. Le backup est donc une copie complète des volumes, snapshots compris.
À partir de là, il est possible de localiser les backups où on le désire à condition de disposer d'une connexion réseau entre les sites.

2.7.2  Configuration

Sur l'Hypercube, chaque zone posséde son propre ZFS. Pour activer le système de backups de cette zone, il suffit d'assigner à ce ZFS la propriété hc:snapshotting avec la valeur yes. L'Hypercube créera automatiquement des backup horaire, journalier et hebdomadaire sous forme de snapshots zfs. Le nombre d'instances à garder pour chaque type de backups est défini dans le fichier de configuration hc-autocleansnap.conf comme vous pouvez le voir ci-dessous. 
~# cat /etc/opt/hypercube/backup/hc-autocleansnap.conf
RETENTION[yearly]=0
RETENTION[weekly]=1
RETENTION[daily]=4
RETENTION[hourly]=6
##RETENTION[minutes]=20
S'il faut préserver des backups sur des systèmes externes comme des disques externes, serveurs d'archivage/backups, LTO ou autres, il suffit de définir la propriété hc:remotebackup avec la valeur yes.
Voci le fonctionnement par défaut de cette synchronisation:
Voici quelques exemples illustrant le fonctionnement

Propriétés et snapshots

~$ zfs get hc:snapshotting,hc:remotebackup srv-files01-01/zones/srv-files01
NAME                      PROPERTY           VALUE              SOURCE
srv-files01-01/zones/srv-files01  hc:snapshotting  yes                local
srv-files01-01/zones/srv-files01  hc:remotebackup  yes                local

:~$ pfexec zfs get -r creation srv-files01-01/zones/srv-files01
NAME                                         PROPERTY  VALUE                  SOURCE
srv-files01-01/zones/srv-files01                     creation  Sun Dec 24  5:20 2023  -
srv-files01-01/zones/srv-files01@weekly-25-19        creation  Mon May 12  5:06 2025  -
srv-files01-01/zones/srv-files01@daily-25-19-15      creation  Thu May 15  5:06 2025  -
srv-files01-01/zones/srv-files01@daily-25-19-16      creation  Fri May 16  5:06 2025  -
srv-files01-01/zones/srv-files01@daily-25-19-17      creation  Sat May 17  5:06 2025  -
srv-files01-01/zones/srv-files01@hourly-25-19-17-21  creation  Sat May 17 21:06 2025  -
srv-files01-01/zones/srv-files01@hourly-25-19-17-22  creation  Sat May 17 22:06 2025  -
srv-files01-01/zones/srv-files01@hourly-25-19-17-23  creation  Sat May 17 23:06 2025  -
srv-files01-01/zones/srv-files01@daily-25-19-18      creation  Sun May 18  5:06 2025  -
srv-files01-01/zones/srv-files01@hourly-25-19-18-05  creation  Sun May 18  5:06 2025  -
srv-files01-01/zones/srv-files01@hourly-25-19-18-06  creation  Sun May 18  6:06 2025  -
srv-files01-01/zones/srv-files01@hourly-25-19-18-07  creation  Sun May 18  7:06 2025  -
srv-files01-01/zones/srv-files01@hourly-25-19-18-08  creation  Sun May 18  8:06 2025  -

Configuration du backup déporté

~# cat /export/home/backup/hc-backup_config
PROPPREFIX=hc
IS_ENCRYPT=0
BKPHOST=10.2.3.4
BKPDS=backuppool/zones/zone-backup/dataset/backup-zones

2.7.3  Extension

Grâce à l'utilisation de propriétés et des plugins du système de backups de l'Hypercube, celui-ci peut facilement être étendu pour supporter les fonctionnalités suivantes:

2.7.4  Restauration à partir de backups

Il peut arriver qu'il faille remonter à des snapshots absents du ZFS local de la zone mais présents sur le serveur de backups.
Plusieurs options se présentent:

Chapter 3
Virtualisation

3.1  Global Zone

L'installation d'OmniOS sur un node porte le nom de Zone Globale. Contrairement aux non-global zones qui peuvent être basculées d'un node à un autre, la zone globale est ättachée" au matériel.

3.2  Non-Global Zones

OmniOS prend en charge à la fois la virtualisation du système d'exploitation léger et la virtualisation complète du matériel à l'aide de non-global zones simplement appelées "zones".
Une zone est une instance virtualisée d'OmniOS qui se comporte comme un système distinct, même si elle fonctionne avec d'autres zones sur la même machine. Les ressources systèmes sont partagées entre les zones et peuvent être partagées et plafonnées à l'aide de diverses techniques.
Dans OmniOS, les systèmes virtualisés sont configurés comme des zones de différents types. Même la virtualisation matérielle est exécutée dans une zone afin de profiter des contrôles de ressources offerts et d'ajouter une deuxième couche de protection à l'isolation déjà fournie par l'hyperviseur.
Les différents types de zones utilisés par l'Hypercube sont

3.3  Zone lipkg

Une zone linked-ipkg (lipkg) est une extension d'une zone ipkg dont le jeu de logiciels installés est lié à celui de la zone globale. Une zone lipkg n'exécute donc que des logiciels OmniOS.
Par défaut, lors d'une mise à jour de packages à partir de la zone globale, les packages du système central dans les zones lipkg sont automatiquement mis à jour en même temps. Il est possible d'étendre cette procédure à la mise à jour de tous les packages et à la mise à jour de plusieurs zones lipkg en parallèle par le biais d'options de ligne de commande ou de propriétés pkg.
Un autre avantage par rapport aux zones ipkg est que les mises à jour de versions majeures peuvent être effectuées sans avoir à détacher et réattacher les zones.
Les zones lipkg peuvent avoir plusieurs environnements de démarrage (BE, Boot Environments), créés soit localement dans la zone, soit gérés automatiquement à partir de la Global Zone au fur et à mesure que les BE y sont créés/détruits.
Même si l'image logicielle est liée à la zone globale, il est parfaitement possible d'installer un ensemble différent de packages dans une zone lipkg tant que les règles de cohérence du système sont respectées.

3.4  Zone lx

Une zone lx fournit un environnement pour l'exécution d'applications binaires compilées pour GNU/Linux. Le code au niveau de l'utilisateur, y compris une distribution Linux complète, peut être exécuté à l'intérieur de la zone.
Une application Linux, jusqu'à une distribution Linux complète, peuvent être exécutées à l'intérieur de la zone.
Une zone lx permet à OmniOS d'héberger et d'exécuter la plupart des applications Linux dans un environnement plus léger qu'une zone Bhyve.

3.5  Zone bhyve

Basé sur OmniOS, l'Hypercube utilise Bhyve comme hyperviseur type 2.
Bhyve prend en charge la virtualisation de la majorité des systèmes d'exploitation
Bhyve prend en charge les installations UEFI et les interfaces émulées VirtIO.
La prise en charge des périphériques repose sur les pilotes de base et VirtIO et prend en charge:

3.5.1  Création manuelle d'une zone

L'ensemble de ces opérations peuvent être faites à l'aide de l'interface graphique.

Créer le zpool de la zone

Deux étapes pour créer un zpool avant d'y installer la zone:

Créer la configuration de la zone

Copier le fichier de configuration modèle vers /tmp et modifier la configuration de la zone selon les besoins 
~$ export ZONE=[zonename]
~$ cp /opt/omnicube/share/vm_tpl.cfg /tmp/${ZONE}.cfg
~$ vi /tmp/${ZONE}.cfg
Si l'adresse MAC n'est pas présente dans la configuration, une adresse MAC sera automatiquement générée à la création de la zone et sera persistante car intégrée dans la configuration de la zone. Pour générer une adresse MAC de type Omnicube, il suffit d'exécuter 
~$ /opt/omnicube/bin/generate_mac_address_vm
Pour un détail complet des attributs possibles, la page suivante peut être consultée: https://man.omnios.org/bhyve.7
Voici un exemple de configuration assez exhaustive avec commentaires explicatifs: 
create -b
# root path de la zone, c'est ici que se trouvent les fichiers liés à la gestion par OmniOS
# Dans /zones/ZONE/root/root se trouve toute ce qui est propre à la brand.
# Les paths définis dans la suite se font par rapport à ce root path.
# /zones/ZONE/root/root/raw/disk0.raw est ainsi défini comme /raw/disk0.raw
set zonepath=/zones/ZONE/root 
# bhyve/kvm/lipkg/lx
set brand=bhyve
# La zone démarre au lancemenet de l'OS si true
set autoboot=false
set ip-type=exclusive
add net
# Nom de l'interface virtuelle de la zone, telle qu'elle sera vue sur OmniOS (ne peut pas contenir de '-' et est limité en nombre de caractères)
set physical="ZONEi0'
# Adresse MAC. En cas d'absence, génération automatique
set mac-addr="8c:a6:82:db:e5:48"
# VLAN dans lequel enfermé la zone
set vlan-id="666"
# Interface physique à laquelle est associé l'interface virtuelle
set global-nic="aggr0"
end
# Inutile dans le cas des raw devices (juste mis à titre de référence)
# Utile dans le cas de KVM ou bhyve avec RDM (Cf. OCUBE_create_vm_extended.md)
add device
set match="/raw/disk0.raw"
end
# Disque de démarrage de la zone, disk0.raw par convention mais peut aussi être nommé bdisk.raw
add attr
set name="bootdisk"
set type="string"
set value="/raw/disk0.raw"
end
# Deuxième disque de la zone
# Pour en ajouter il suffit de dupliquer cette section avec name=disk[n<8]
add attr
set name="disk0"
set type="string"
set value="/raw/disk1.raw"
end
# A spécifier obligatoirement en cas de zone Windows
add attr
set name="type"
set type="string"
set value="windows"
end
# Mémoire de la zone. Sans unité (K, M, G or T), l'unité par défault est le Mb. 
add attr
set name="ram"
set type="string"
set value="8G"
end
# Le firmware UEFI only
add attr
set name="bootrom"
set type="string"
set value="BHYVE_RELEASE"
end
# Priorité de la zone
add attr
set name="priority"
set type="string"
set value="4"
end
# Accès VNC
# Sera activé par /opt/omnicube/bin/activate_zone_vnc.sh ${ZONE} ${PORT}
# Si le port est déjà défini dans la confi comme ci-dessus /opt/omnicube/bin/activate_zone_vnc.sh ${ZONE} suffit
add attr
set name="vnc"
set type="string"
set value="rfb=0.0.0.0:6072,unix=/tmp/vm.vnc,w=1680,h=1050"
end
# Défini le controlleur du disque ahci-hd, nvme ou virtio-blk
# Pour spécifier un autre controlleur associé à un disque secondaire, il suffit de dupliquer la section en spécifiant l'id du
# disque dans name=diskif[n<8]
add attr
set name="diskif"
set type="string"
set value="nvme"
end
# Défini la topologie CPU associée à la zone
add attr
set name="vcpus"
set type="string"
set value="sockets=1,cores=2,threads=1"
end

Créer et installer la zone

~$ pfexec su -
~# export ZONE=[zonename]
~# pfexec zonecfg -z ${ZONE} -f /tmp/${ZONE}.cfg
~# pfexec zoneadm -z ${ZONE} install
~# pfexec mkdir /zones/${ZONE}/root/root/raw
Pour ajouter un disque à la configuration de la zone après sa création: 
~# zonecfg -z ${ZONE} 'add attr; set name=disk0; set type=string; set value=/raw/disk1/raw; end; verify'
Pour ajouter plusieurs disques, une boucle peut être utilisée.

Installer le boot disk à partir des modèles

~$ pfexec su - root
~# cd /zones/${ZONE}/root/root/raw
~# $ ls  /iso/templates/
debian13tpl_oc_v1_260218.tar         ubuntu24tpl_oc_v1_260217.tar.sha256  win2019tpl_oc_v1_260224.tar          win2022tpl_oc_v1_260224.tar.sha256
debian13tpl_oc_v1_260218.tar.sha256  win11tpl_oc_v1_260224.tar            win2019tpl_oc_v1_260224.tar.sha256   win2025tpl_oc_v1_260224.tar
ubuntu24tpl_oc_v1_260217.tar         win11tpl_oc_v1_260224.tar.sha256     win2022tpl_oc_v1_260224.tar          win2025tpl_oc_v1_260224.tar.sha256
~# gtar xvfS /iso/templates/win11tpl_oc_v1_260224.tar 
win11tpl/README
win11tpl/win11_disk0.raw
~# mv win11tpl/win11_disk0.raw disk0.raw # device spécifié comme bootdisk
~# rm -rf win11tpl/
S'il faut agrandir la taille du disque ne pas oublier de l'étendre dans la zone elle-même. Les modèles fournis permettent tous d'étendre le disque sans le besoin d'outils extérieurs 
~# cd /zones/${ZONE}/root/root/raw
~# ls -lh
total 36576581
-rw-r--r--   1 root     root         50G Feb 17 07:12 disk0.raw
~# truncate -s 80G disk0.raw
~# ls -lh
total 36576581
-rw-r--r--   1 root     root         80G Feb 17 07:14 disk0.raw
Pour créer d'autres disques, il suffit d'utiliser la commande truncate 
~# truncate -s 100G disk1.raw
~# ls -lh disk1.raw
-rw-r--r--   1 root     root         100G Feb 17 07:16 disk1.raw

Booter la zone

Tous les modèles, à l'exception de Windows 11, permettent un accès console 
~$ pfexec zoneadm -z ${ZONE}  boot ; pfexec zlogin -e '#' -C ${ZONE}
Les logs de la zone sont situés dans les directories suivants:

Activer la console VNC

~# /opt/omnicube/bin/activate_zone_vnc.sh ${ZONE} [FREE-VNC-PORT]

3.6  Réseau

3.6.1  VNIC

Lors de la configuration d'une zone, une ou plusieurs VNIC peuvent être créées sur une interface ethernet physique ou LACP de la zone globale. 
~# dladm show-vnic v100if90
LINK         OVER       SPEED    MACADDRESS        MACADDRTYPE VID  ZONE
v100if90     aggr0      10000    0:16:3e:18:c1:92  fixed       100  test-lipkg

3.6.2  VLAN

Chaque zone peut être configurée dans un ou plusieurs VLAN puisque chaque VNIC peut se voir attribué un VLAN ID.

Figure 3.1: Configuration d'une zone

3.7  Disponibilité

Techniquement, rien n'interdit d'installer une zone sur un disque local au node. Toutefois, pour une évidente raison de disponibilité, il est recommandé d'installer chaque zone sur un miroir d'au moins deux disques provenant des deux nodes différents. De la sorte, une cas de défaillance d'un node il suffit d'importer les disques sur un autre et de redémarrer les zones correspondantes.
Le mirroring entre node permet d'assurer un RPO de zéro et un RTO égal au temps de redémarrage des zones. Autrement dit la défaillance du node n'entraînera aucune perte de données et un downtime limité au temps de redémarrage des zones sur un autre node.

3.8  Migration d'une zone

La procédure ici décrite permet de migrer à froid et manuellement une zone d'un node vers un autre.
Sur le node origine sur lequel la zone tourne:
Sur le node cible, vers lequel la zone est migrée, faire les opérations en sens inverse

Chapter 4
Monitoring

4.1  FMD - Fault Management Daemon

FMD est un démon qui s'exécute en arrière-plan sur chaque système. FMD reçoit des informations de télémétrie relatives aux problèmes détectés par le logiciel système, diagnostique ces problèmes et lance des activités d'auto-réparation proactives, telles que la désactivation des composants défectueux. Le cas échéant, le gestionnaire de pannes envoie également un message au service syslogd pour informer un administrateur qu'un problème a été détecté. Le message dirige les administrateurs vers un article de la base de connaissances sur http://illumos.org/msg, qui explique plus en détail l'impact du problème et les réponses appropriées.
Chaque problème diagnostiqué par le gestionnaire de pannes se voit attribuer un identifiant unique universel (UUID). L'UUID identifie de manière unique ce problème particulier sur n'importe quel ensemble de systèmes. L'utilitaire fmdump peut être utilisé pour afficher la liste des problèmes diagnostiqués par le gestionnaire de pannes, ainsi que leurs UUID et les identifiants des messages des articles de la base de connaissances.
L'utilitaire fmadm peut être utilisé pour afficher les ressources du système considérées comme défectueuses. L'utilitaire fmstat peut être utilisé pour afficher les statistiques conservées par le gestionnaire de pannes. Le gestionnaire de pannes est lancé automatiquement au démarrage du système d'exploitation, il n'est donc pas nécessaire d'utiliser directement la commande fmd.

4.2  SMF - Service Management Facility

La fonctionnalité de gestion des services Solaris (OmniOS) définit un modèle de programmation permettant de fournir des applications fonctionnant en permanence, appelées services. Cette fonctionnalité fournit également l'infrastructure nécessaire à l'exécution des services. Un service peut représenter une application en cours d'exécution, l'état logiciel d'un périphérique ou un ensemble d'autres services. Les services sont représentés dans le cadre par des objets d'instance de service, qui sont des enfants d'objets de service. Les objets d'instance peuvent hériter ou remplacer la configuration de l'objet de service parent, ce qui permet à plusieurs instances de service de partager des informations de configuration. Tous les objets de service et d'instance sont contenus dans un "scope" qui représente un ensemble d'informations de configuration. La configuration de l'instance Solaris locale est appelée "scope" localhost et est le seul "scope" actuellement pris en charge.
Chaque instance de service est nommée à l'aide d'un identifiant de ressource de gestion des erreurs (FMRI) avec le schéma svc:. Par exemple, le démon syslogd démarré au démarrage du système est l'instance de service par défaut nommée:
svc://localhost/system/system-log:default svc:/system/system-log:default system/system-log:default
Dans l'exemple ci-dessus, "default" est le nom de l'instance et ßystem/system-log" est le nom du service. Les noms de service peuvent être composés de plusieurs éléments séparés par des barres obliques (/). Tous les éléments, à l'exception du dernier, composent la catégorie du service. Les services spécifiques à un site doivent être nommés avec une catégorie commençant par ßite".
Une instance de service est soit activée, soit désactivée. Tous les services peuvent être activés ou désactivés à l'aide de la commande svcadm.
La liste des instances de services gérés sur un système peut être affichée à l'aide de la commande svcs.

4.3  SNMP - Simple Setwork Management Protocol

La plupart du système de monitoring de OmniOS se base sur SNMP. Pour l'authentification, OmniOS supporte les versions de SNMP v1, v2 et v3.
Grâce à FMD et SMF, Omnios possède un système intégré et efficace de gestion d'événements, qu'il suffit de connecter aux services SNMP. En cas de problème matériel, applicatif ou de configuration, l'OS peut lancer des SNMP traps doublés au besoin d'alertes par e-mail.

4.3.1  Installation des packages

~# pkg install -v  pkg:/system/management/snmp/net-snmp\
                   pkg:/service/fault-management/snmp-notify\
                   pkg:/service/fault-management/smtp-notify
Un ficher snmpd.conf.tpl est fourni en annexe pour service de base à /etc/net-snmp/snmp/snmpd.conf.
La configuration des utilisateurs SNMPv3 se fait à l'aide de l'outil net-snmp-config. 
~# net-snmp-config --create-snmpv3-user -A authsample -X encsample -x DES -a MD5 sysmon
Une fois la configuration effectuée, il suffit d'activer les services correspondants 
~# svcadm enable svc:/application/management/net-snmp
~# svcadm enable svc:/system/fm/snmp-notify:default
Pour ce qui est des mesures de performance de OmniOS et de tous les types de machines virtuelles supportées, ces informations peuvent aussi être collectées par SNMP. Concernant l'hypercube, une appliance basée sur OpenNMS peut être livrée en cas de besoin.

Chapter 5
Fair share scheduler

5.1  Introduction

Le Fair Share Scheduler (planificateur équitable - FSS) garantit les performances des applications/zone en allouant explicitement des parts des ressources CPU aux projets.
Un "share" indique le droit d'un projet aux ressources CPU disponibles. Comme les shares n'ont de sens que par rapport aux shares d'autres projets, la quantité absolue de shares n'a pas d'importance. Tout nombre proportionnel au droit souhaité sur le CPU peut être utilisé.

5.2  Objectif

Les objectifs du planificateur FSS diffèrent de ceux de la time-sharing scheduling class (classe de planification traditionnelle à partage de temps - TS). En plus de planifier des LWP individuels, le planificateur FSS planifie les projets les uns par rapport aux autres, rendant impossible pour un projet d'acquérir plus de cycles CPU simplement en exécutant plus de processus simultanément.

5.3  Fonctionnement

Le droit d'un projet est calculé individuellement par le FSS indépendamment pour chaque ensemble de processeurs si le projet contient des processus qui leur sont liés. Si un projet s'exécute sur plusieurs ensembles de processeurs, il peut avoir des droits différents sur chaque ensemble. Le droit d'un projet est défini comme le rapport entre le nombre de shares attribuées à un projet et la somme des shares de tous les projets actifs s'exécutant sur le même ensemble de processeurs.
Un projet actif est un projet qui a au moins un processus en cours d'exécution ou exécutable. Les droits sont recalculés chaque fois qu'un projet devient actif ou inactif, ou chaque fois que le nombre de shares est modifié.
Les ensembles de processeurs représentent des machines virtuelles dans la classe de planification FSS et les processus sont planifiés indépendamment dans chaque ensemble de processeurs. Autrement dit, les processus ne sont en concurrence les uns avec les autres que s'ils s'exécutent sur le même ensemble de processeurs.
Lorsqu'un ensemble de processeurs est détruit, tous les processus qui y étaient liés sont déplacés vers l'ensemble de processeurs par défaut, qui existe toujours. Les ensembles de processeurs vides (c'est-à-dire les ensembles qui ne contiennent aucun processeur) n'ont aucune incidence sur le comportement du planificateur FSS.
Au fur et à mesure de l'exécution des projets, leur utilisation du CPU s'accumule dans le temps.
Le planificateur FSS réduit périodiquement l'utilisation du CPU de chaque projet en la multipliant par un facteur de décroissance, garantissant ainsi que l'utilisation récente du CPU a plus de poids lorsqu'elle est prise en compte pour la planification. Le planificateur FSS ajuste en permanence les priorités de tous les processus afin que l'utilisation relative du CPU de chaque projet converge vers son droit.
Bien que le FSS soit conçu pour répartir équitablement les cycles sur une longue période, il est possible que les projets ne reçoivent pas leur part allouée de cycles CPU en raison d'une demande inégale. Cela rend peu fiable l'analyse ponctuelle et instantanée des données de performance du FSS.
Notez que la part n'est pas la même chose que l'utilisation. Un projet peut se voir allouer 50 % du système, bien qu'il n'utilise en moyenne que 20 %. Les shares servent à limiter l'utilisation du CPU d'un projet uniquement lorsqu'il y a concurrence avec d'autres projets s'exécutant sur le même ensemble de processeurs.
En l'absence de concurrence, l'utilisation peut être supérieure à la part attribuée. L'attribution d'un petit share à un projet très sollicité le ralentit, mais ne l'empêche pas de terminer son travail si le système n'est pas saturé.

5.4  Configuration

La configuration des shares de CPU est gérée par le serveur de noms en tant que propriété de la base de données project.
Dans l'exemple suivant, une entrée dans le fichier /etc/project définit le nombre de shares pour le projet x-files à 10: 
 x-files:100::::project.cpu-shares=(privileged,10,none)
Les projets dont le nombre de shares n'est pas défini se voient attribuer un share chacun. Cela signifie que ces projets sont traités avec la même importance. Les projets avec 0 share ne s'exécutent que lorsqu'aucun projet avec des shares non nul ne se dispute le même ensemble de processeurs. Le nombre maximal de shares pouvant être attribuées à un projet est 65535.
Vous pouvez utiliser la commande prctl pour déterminer l'affectation actuelle des shares pour un projet donné : 
~$ prctl -n project.cpu-shares -i project x-files
ou pour modifier le nombre de shares si vous disposez des privilèges root: 
~# prctl -r -n project.cpu-shares -v 5 -i project x-files
Consultez la page de manuel prctl pour plus d'informations sur la modification et l'examen des contrôles de ressources associés aux processus, tâches ou projets actifs sur le système. Consultez resource_controls pour une description des contrôles de ressources pris en charge dans la version actuelle du système d'exploitation Solaris/OmniOS.
Par défaut, le système de projet (ID de projet 0) inclut tous les démons système démarrés par les scripts d'initialisation et dispose d'un nombre ïllimité" de partages. Autrement dit, il est toujours planifié en premier, quel que soit le nombre de partages attribués à d'autres projets.
La commande suivante définit FSS comme planificateur par défaut pour le système : 
~# dispadmin -d FSS
Cette modification prendra effet au prochain redémarrage. Vous pouvez également déplacer les processus de la classe de planification à temps partagé (ainsi que le cas particulier de init) vers la classe FSS sans modifier votre classe de planification par défaut et sans redémarrer en devenant root, puis en utilisant la commande priocntl, comme indiqué dans l'exemple suivant: 
~# priocntl -s -c FSS -i class TS
~# priocntl -s -c FSS -i pid 1

Footnotes:

1La Hardware Compatibility List non-exhaustive peut être consultée à l'adresse suivante: https://www.illumos.org/hcl/
2L'utilisation d'un contrôleur RAID hardware ne fait "que" déplacer le Single Point of Failure (SPOF) des disques vers le contrôleur lui-même. La défaillance de ce dernier est certes moins grave puisqu'elle n'implique pas la perte de données, mais elle nécessite quand même une intervention physique qui prend un temps certain.
3Les machines virtuelles Windows nécessitent des pilotes VirtIO.