Cluster Dédié
Introduction
La classe de service Standard est basée sur des ressources mutualisées, pour lesquelles Orange Business fournit des licences en mode Cloud, c’est-à-dire avec un paiement à l’usage des ressources. Cependant, pour répondre à des contraintes spécifiques du Client (par exemple le besoin d’utiliser les Licences du Client), Orange Business propose la privatisation d’un groupe de serveurs physiques au sein de la plateforme mutualisée.
Orange Business fournit les outils nécessaires pour vous permettre de vérifier que vos VM n’ont pas fonctionné en dehors de ce cluster dédié, afin de garantir le respect des règles d’utilisation des licences.
Principe
Vous pouvez commander plusieurs serveurs physiques pour constituer un « Provider vDC » dédié, sur lequel un vDC est construit, regroupant toutes les ressources des serveurs physiques. Il est également possible de demander la création de plusieurs vDC sur votre cluster.
Le mode d’allocation des ressources recommandé est le « Reservation Pool ». Ce mode d’allocation des ressources présente plusieurs avantages :
- Les limites sont fixées au niveau du vDC, qui sont, dans notre cas, alignées sur les capacités du cluster physique ; ce qui permet aux VM d’accéder à plus de ressources, dès lors qu’elles sont disponibles dans le vDC (« burst mode »).
- Le pourcentage de ressources garanties et la fréquence vCPU sont positionnables lors de la création du vDC, ce qui va permettre au Client de gérer lui-même le ratio de consolidation.
Les paramètres positionnables lors de la création du vDC sont :
- Le pourcentage de réservation de la CPU
- Le pourcentage de réservation de la RAM
- La fréquence des vCPU en GHz
En plus de ces paramètres, le nombre de VM que vous choisissez de créer dans le vDC déterminera le taux de surbooking.
Plus d’information sur le modèle d’allocation des ressources « Reservation Pool » sur le site de vmware.
Haute disponibilité
Pour garantir la disponibilité des applications en cas de perte d’une lame, le cluster dédié doit être dimensionné en tenant compte de cette éventualité. Une lame défectueuse sera remplacée par Orange Business Services dans les 48 heures. Pendant ce délai, les VM doivent pouvoir fonctionner sur un cluster amputé d’une lame sans impact significatif sur les performances des applications hébergées.
À noter !
Ce dimensionnement est de la responsabilité du Client
Gestion du capacitaire
La gestion du capacitaire est à l’initiative du Client. Orange Business Services fournira au Client des indicateurs VMware permettant de suivre les performances globales du cluster, ainsi que les performances des VM.
Important :
- La décision de modification de la taille du cluster est de la responsabilité du Client
- Le dimensionnement du cluster dédié doit prendre en compte l’éventualité de perte d’une lame sans impact sur le bon fonctionnement du service herbergé
Le délai de mise en place d’une lame par Orange Business Services est généralement de quelques minutes, et cette opération est réalisée en ligne par vous dans votre Espace Client Cloud.
Les autres ressources (stockage, réseau, etc.) sont approvisionnées selon le processus standard Flexible Computing Advanced et sont facturées selon la fiche tarifaire en vigueur.
Exemple de configuration
Lames de 56 cœurs/576 Go de RAM et taux de surbooking cible de 1,5
| Nombres de lames de 56 coeurs et 576 Go de RAM | 3 | 4 | 5 |
| Nombre de vCPU total disponible | 168 | 224 | 280 |
| vCPU disponibles en cas de perte d’une lame | 112 | 168 | 224 |
| Taux de surbooking (vCPU/coeur physique) | 1,5 | 1,5 | 1,5 |
| Capacité de pool de ressources | |||
| vCPU (nominal) | 252 | 337 | 420 |
| RAM (nominal) | 1728 | 2304 | 2880 |
| vCPU (avec perte d’une lame) | 168 | 224 | 280 |
| RAM (avec perte d’une lame) | 1152 | 1728 | 2304 |
Souscription d’un cluster dédié
La taille minimale d’un cluster est de trois serveurs. La facturation est réalisée mensuellement sur la base du nombre de serveurs physiques réservés, et en fonction de leurs caractéristiques (voir la fiche tarifaire).
Orange Business Services fournit les serveurs physiques avec les caractéristiques suivantes :
| Caractéristiques | Type 1 | Type 2 |
| CPU | Intel xeon Gold | Intel xeon Gold |
| Fréquence CPU | 2,2 GHz | 3 GHz |
| Nombre de CPU | 2 | 2 |
| Nombre de core / CPU | 28 | 24 |
| Nombre de coeurs physiques / lame | 56 | 48 |
| RAM | 576 Go | 276 Go |
| Usage | Cluster VMware dédié | Cluster VMware dédié |
Note: Le modèle Type 3 n’est plus commercialisé.
Une lame rajoutée en cours de mois est facturée au prorata temporis du nombre de jours où elle est active dans le mois.
La souscription d’un cluster dédié et l’ajout d’une lame sont réalisés à partir de l’Espace Client Cloud, section « Demandes > Demander un changement ».
Stockage
Seul le stockage dédié est disponible pour un cluster dédié. En effet, un cluster dédié est un « Provider vDC » (PvDC) dédié à un client, et le stockage (datastore) affecté un PvDC ne peut être partagé avec un autre PvDC.
Classes de Disponibilités
Sur le campus de Datacenter de Val de Reuil, la plateforme NGP est déployée sur deux salles, chacune étant totalement indépendante de l’autre (énergie, refroidissement, réseaux), ce qui permet de proposer pour les VM d’un vDC plusieurs classes de disponibilité :
| Classe de disponibilité | Nombre de vDC | Disponibilité du service | Configuration | Localisation des VMs | Mécanisme | Choix de la localisation des VMs par le client | Impact sur perte d’une salle | SLA de disponibilité du vDC |
| One Room |
1 |
Val-de-Rueil et Chartres |
1 vDC avec une seule politique de stockage | Salle définié | Les VM sont localisée dans la salle sélectionnée à la commande du cluster dédié | oui | Arrêt des VM | 99,95% |
| Dual Room | 1 | Val-de-Rueil | 1 vDC avec deux politiques de stockage (une par salle) exemple : SILVER_R1 et SILVER_R2 |
Salle 1 et Salle 2 |
Les VM sont localisées dans une salle grâce à la politique de stockage choisie pour les créer. | oui | Arrêt des VM localisées dans la salle en défaut |
99,95% |
| Dual Room | 2 | Val-de-Rueil | 2 vDCs avec chacun une politique de stockage (par salle)exemple : 1 vDC with GOLD_R1 et 1 vDC with GOLD_R2 | Salle 1 et Salle 2 |
Les VM sont localisées dans une salle grâce à la politique de stockage choisie pour les créer. | oui | Arrêt des VM localisées dans la salle en défaut |
99,95% |
| HA Dual Room | 1 | Val-de-Rueil | 1 vDC avec une seule politique de stockage de type double salle (Le stockage est répliqué entre deux salles) | Salle 1 et Salle 2 |
Les VM sont réparties aléatoirement sur 2 salles selon les règles de capacité, sur cluster étendu (compute + stockage) | oui, avec règles anti-affinités | Arrêter, redémarrer les VM de la salle défaillante | 99,95% |
| Dual Site | 2 | Val-de-Rueil et Chartres |
1 vDC avec une politique de stockage (une par site) | DC1 et DC2 | Les VMs sur le deuxième site sont dormantes avec une politique du service DRaaS | oui | Arrêt des VM localisées dans la salle en défaut |
99,99% |
La description détaillée des classes de disponibilité est ici : Classes de disponibilité (mauvais lien)
Retour au Catalogue de services.
Topologies de cluster dédié
One Room :
Le principe du cluster dédié mono-site permet au client de disposer d’un pool de ressources dédié sur la zone IaaS externe et interne, tout en définissant ses propres classes de service vCPU. Il est important de noter qu’un cluster dédié doit être composé d’un minimum de 3 nœuds et bénéficie d’un datastore dédié, quelles que soient les ressources requises.
Dual Site:
Le principe du cluster dédié dual site est de pouvoir répliquer les machines virtuelles de l’org-VDC du Site A vers le site B en utilisant VDCA. Il est important de rappeler que nous avons toujours une interruption de service. Ci-dessous, nous avons un exemple de diagramme pour un environnement déployé manuellement pour un client final.
HA Dual Room :
La topologie HADR « double salle haute disponibilité » consiste en un seul cluster VMware étendu réparti uniformément sur deux salles. La topologie du réseau se compose de plusieurs VLAN étendus. En cas de panne de salle, les VM redémarrent de l’autre côté par le mécanisme VMware HA et également l’équilibrage de charge via le service VMware DRS. un exemple de cluster dédié de 6 nœuds, trois seront sur la salle 1 et les 3 autres sur la salle 2. Pour ce faire, nous utilisons le datastore Hypermetro, répliqué et disponible depuis les 2 salles (réplication synchrone avec écriture en Y).
Dans cette topologie, on est en théorie sur un RPO nul. HADR est envisagé dans un metrocluster pour le stockage, le niveau de ce service n’existe pas pour le Dual Site
4 serveurs minimum pour le HA Dual Room
