Wiki Cloud Avenue

Cluster Dédié

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 permettant au Client de vérifier que ses VM n’ont pas pu fonctionner en dehors de ce cluster dédié, afin que le Client puisse s’assurer qu’il respecte les règles d’utilisation des Licences du Client.

Le Client commande plusieurs serveurs physiques afin de constituer un « Provider vDC » qui lui est dédié, et sur lequel un vDC est construit, regroupant ainsi la totalité des ressources embarquées dans les serveurs physiques. A noter que le Client peut demander la création de plusieurs vDC sur son 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, c’est le nombre de VM que le Client va choisir de créer dans le vDC qui va déterminer le taux de surbooking.

Plus d’information sur le modèle d’allocation des ressources « Reservation Pool » sur le site de vmware.

Afin de ne pas compromettre la disponibilité des applications en cas de perte d’une lame, le cluster dédié doit être dimensionné par le Client en prenant en compte la perte d’une lame. Une lame défectueuse sera remplacée par Orange Business Services dans les 48h. Cependant, dans ce laps de temps, les VM doivent pouvoir fonctionner sur un cluster amputé d’une lame sans impact significatif sur les performances des applications hébergées.

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 (opération réalisée en ligne par le Client dans son 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 ».

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é

Retour au Catalogue de services

Topologies de cluster dédié

One Room :

Le principe du cluster dédié mono-site est que le client dispose d’un pool de ressources dédié sur la Zone IaaS externe et interne et on peut définir en même temps ses propres classes de service vCPU. il a noté qu’un cluster dédié, quelles que soient les ressources requis, doit être composé d’un minimum de 3 nœuds et bénéficie d’un datastore dédié

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