Datacenter Virtuel

Aperçu

Un Virtual Datacenter (vDC) est un ensemble de ressources comprenant :

• de la puissance de calcul, exprimée en GHz ou en vCPU, et en quantité de RAM,
• de la capacité de stockage pour les disques virtuels des VM,
• une (ou plusieurs) passerelle Edge de vDC (VE), fournissant des connexions à des réseaux externes (internet ou BVPN), ainsi que des réseaux internes au vDC.

La puissance de calcul (CPU + RAM) et le stockage sont disponibles selon plusieurs classes de services.

À noter !

À un vDC correspond une classe de service et un mode d’allocation des ressources (PAYG ou Allocation Pool). Il n’est pas possible de changer le mode d’allocation des ressources d’un vDC après sa création. Si vous souhaitez changer le mode d’allocation des ressources de votre vDC, vous devez commander un nouveau vDC et y migrer vos vApp/VM.

Caractéristiques des vDC selon les classes de performance

Classe de services		Eco *	Standard	High Performance	VOIP *
Limites des VMs (vCPU / RAM / Stockage)		6 vCPU / 16G / 4 To	8 vCPU / 64G / 6 To	40 vCPU / 128G / 6 To	32 vCPU / 128G / 6 To
Usage		– VM Windows – Environnements de développement, tests, labs	Tout	– Big Data – Temps réel – Calcul intensif	– IPBX – Temps réel
Modes d’allocation		PAYG et Allocation Pool	PAYG et Allocation Pool	Allocation Pool	Réservation Pool
One Room		▲	▲	▲	▲
Dual Room		▲	▲	▲	▲
HA Dual Room		△	▲	▲	△
Modes de facturation		PAYG, Réservé et DRaaS	PAYG, Réservé et DRaaS	PAYG et Réservé	Réservé
Fréquence vCPU	PAYG ou DRaaS	2,2 GHz	2,2 GHz	2,2 GHz	3 GHz
	Réservé	1,2 GHz mini	1,2 GHz mini	2,2 GHz	3 GHz

À noter !

Le stockage maximum supporté par VM n’est pas une limitation technique. Il est possible d’aller au-delà de ces limites. Cependant, en dehors de ces limites, Orange Business ne pourra garantir ses engagements contractuels (voir le Descriptif de Service pour les mentions légales).Dans la classe de service VOIP, le paramétrage mis en place désactive le vMotion (le déplacement automatique d’une machine virtuelle d’un serveur physique vers un autre) et le VMware HA (le redémarrage automatique d’une VM hébergée sur un serveur physique en panne sur un autre serveur physique), ceci afin d’être compatible avec le mode de fonctionnement de la majorité des solutions de téléphonie sur IP. Cependant, à des fins de maintenance, le DRS entièrement automatisé (vMotion) peut être activé pendant la fenêtre de maintenance pour vider l’ESXi qui nécessite une mise à niveau.

* Les classes de service Eco et VOIP ne sont pas disponibles sur le datacenter de Chartres.

Classes de disponibilité

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é	Logo dans le formulaire de création de vDC de l’espace client	Nombre de vDC	Configuration	Localisation des VM	Mécanisme	Choix de la localisation des VM par le Client	Impact sur perte d’une salle	SLA de disponibilité du vDC
One Room		1	1 vDC avec une seule politique de stockage	Non prédictible	les VM sont distribuées de manière aléatoire sur les 2 salles en fonction des règles capacitaires.	non	Arrêt de tout ou partie des VM	99,95%
Dual Room		1	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	2 vDC avec chacun une politique de stockage par salle, par exemple : 1 vDC avec du GOLD_R1 1 vDC avec du 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	1 vDC avec une seule politique de stockage de type Dual Room (stockage répliqué entre les 2 salles)	Salle 1 et Salle 2	les VM sont distribuées de manière aléatoire sur les 2 salles en fonction des règles capacitaires, sur des clusters étendus (compute + stockage)	oui, avec règles d’anti-affinité	Arrêt / redémarrage des VM de la salle en défaut	99,99%

La description détaillée des classes de disponibilité est ici : Classes de disponibilité

Gestion des ressources d’un vDC

L’allocation en ressources d’un vDC est choisie par vous. Cette allocation est paramétrable lors de la commande du vDC, puis modifiable via une demande de changement, éventuellement plusieurs fois selon vos besoins.

L’allocation en ressources d’un vDC constitue une limite « physique » que les VM ne pourront dépasser pour pouvoir s’exécuter.

Une VM pourra démarrer si les deux conditions suivantes sont remplies :

• ∑ des vCPU des VM déjà démarrées + nombre de vCPU de la VM à démarrer ≤ allocation totale en nombre de vCPU du vDC
• ∑ de RAM des VM déjà démarrées + quantité de RAM de la VM à démarrer ≤ allocation totale de RAM du vDC

Modes d’allocation de la puissance de calcul

Mode d’allocation « PAYG »

Dans ce mode d’allocation, les ressources sont exprimées en nombre de vCPU (= Limite en GHz / fréquence vCPU) et en Go de RAM. Dans un vDC configuré en mode « PAYG », l’allocation en ressources d’une VM se fait au niveau de la VM. Lorsque la VM démarre, son allocation en vCPU et RAM est soustraite du montant total alloué au vDC. Une VM ne pourra jamais consommer plus que son allocation. Il s’agit d’une limite.

Le mode de facturation adopté est alors le paiement à l’usage (PAYG).

Mode d’allocation « Allocation Pool »

Dans ce mode d’allocation, les ressources sont exprimées en GHz et Go de RAM. Ces ressources sont une limite maximum d’utilisation avec une réservation minimale garantie. L’allocation en ressources pour toutes les VM se fait globalement lors de la création du VDC. À la différence du PAYG, il n’y a pas de limite par VM et sa consommation peut s’ajuster selon les besoins et l’utilisation totale des VMs du VDC (sans dépasser la limite totale).

Pour l’allocation en ressources, la fréquence du vCPU est définie par vous en mode de facturation réservé, lors de la commande du vDC, avec un minimum de 1,2 GHz.

Le mode « Allocation Pool » permet au vCPU d’une VM initialement configuré de consommer jusqu’à la valeur maximum fournie par un processus physique (exemple : 2,2 GHz). Cet effet « burst » s’activera sous certaines conditions :

• Une VM soumise à une forte charge CPU réclame ponctuellement de la puissance supplémentaire
• Il reste des GHz disponibles (non consommés) dans le vDC.

Ce mode d’allocation est recommandé pour les vDC dont les VM sont allumées en permanence.

Mode d’allocation « Reservation Pool »

Dans ce mode d’allocation, les ressources sont exprimées en GHz et Go de RAM. Mais contrairement au mode « Allocation Pool » il s’agit d’une réservation ferme et donc tout autant un minimum garanti tout autant qu’un maximum de réservation garanti. L’allocation en ressources réservées (donc minimum garanti) d’une VM se fait cette fois individuellement VM par VM par l’administrateur de l’organisation tout au long de la vie du VDC. C’est un contrôle fin et total par l‘administrateur de l’organisation de sa ressource.

Les ressources allouées à chaque VM sont garanties à 100% pour les VM, ce qui nécessite un dimensionnement adapté lors de la définition du VDC pour que toutes les VM destinées à fonctionner puissent démarrer.

Ce principe d’allocation des ressources est utilisé pour les vDC de type VOIP, ce qui permet aux applications de téléphonie ou visioconférence de fonctionner avec le maximum d’isolation possible vis-à-vis de leur environnement.

Notes

• On pourrait penser que le mode « Reservation pool » est équivalent au mode « Allocation Pool » où on aurait réservé 100% de la limite. Ce n’est pas le cas car seul le mode « Reservation Pool » permet une réservation au niveau de la VM.
• Si toutefois on désire réserver autant que la limite sans jamais avoir le besoin de réserver au niveau de la VM on peut prendre un mode « allocation pool » (ce n’est pas recommandé pour les applications de type VOIP).

Modes de facturation de la puissance de calcul

Deux modes de facturation sont disponibles.

Modes de facturations	PAYG (A l’usage) & DRaaS	Au Réservé
Allocation des ressources	PAYG	Allocation Pool Réservation Pool
Facturation	Ressources allouées aux VM démarrées	100% des ressources du vDC

Modes de facturation « PAYG » et « DRaaS »

PAYG facturées (UO)	Puissance de calcul	RAM
Ressources facturées (UO)	vCPU	Go
Quantités facturées	Nombre de vCPU alloué à chaque VM démarrée x nombre de minutes / jour	Nombre de RAM alloué à chaque VM démarrée x nombre de minutes / jour

Le temps d’utilisation est décompté à la minute.

Un vDC en mode DRaaS est utilisé dans le cas de la mise en place de la réplication de VM entre l’infrastructure privée du Client (On Premise) et la plateforme Cloud Avenue.

Mode de facturation « Réservé »

Dans ce modèle, c’est l’ensemble des ressources GHz et RAM du vDC qui est facturé de manière forfaitaire. Ce principe permet au Client de bénéficier de tarifs plus attractifs.

Réservé	Puissance de calcul	RAM
Ressources facturées (UO)	GHz	Go
Quantités facturées	Quantité de GHz allouée au vDC x nombre de jours / mois	Quantité de Go allouée au vDC x nombre de jours / mois

Exemple

Un vDC de 34 GHz et 20 Go de RAM est souscrit en « Réservé ». La facturation, mensuelle, de ce vDC se calcule comme suit :

• 34 GHz x prix unitaire x 30 jours x 24h
• 20 Go de RAM x prix unitaire x 30 jours x 24h

Ce modèle permet également au client de choisir son niveau de sur-allocation. Par exemple, en choisissant un vCPU à 1,7 GHz, il sera possible de démarrer 20 VM de 1 vCPU et 1 Go de RAM. Et les VM les plus gourmandes en CPU pourront alors puiser dans les GHz qui ne sont pas consommés par les VM les moins actives (effet Burst), mais dans la limite :

• des GHz disponibles au global dans le vDC (34 GHz)
• de la fréquence du CPU physique : 2,2 GHz.

Focus sur les classes de disponnibilité

Aperçu

Sur le campus de Datacenter de Val de Reuil, l’infrastructure Cloud Avenue 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 un vDC plusieurs classes de disponibilité.

Principes de base

• La localisation des VM est définie par la localisation des « datastore » utilisés dans la politique de stockage mise à disposition dans un vDC. La VM sera exécutée dans la salle hébergeant le « datastore » utilisé par la VM. Une politique de stockage peut est constituée de différents « datastore » répartis sur les 2 salles.
• L’infrastructure portant les T0 et T1 est par défaut en très haute disponibilité sur les 2 salles. La perte d’une salle n’affectera pas la connectivité des vDC.

One Room

Par défaut, les ressources de votre vDC sont fournies par les deux salles de manière aléatoire, en fonction des règles capacitaires. Vous ne pouvez pas choisir la salle sur laquelle vos VM seront déployées, ce processus étant entièrement transparent pour vous.

Cette configuration est disponible pour toutes les classes de performance.

Dual Room 1 vDC

Vous choisissez un vDC avec deux politiques de stockage, une dans chaque salle.

Cette configuration permet de choisir la localisation des VM.

La résilience du service reposera sur les mécanismes applicatifs (mode cluster des VM, ferme de serveurs web configurée dans le Load Balancer, etc.)

L’avantage d’avoir un seul vDC est dans la gestion capacitaire, qui est simplifiée par rapport à 2 vDC (un dans chaque salle).

Les tarifs One Room s’appliquent.

Cette configuration est disponible pour toutes les classes de performance.

Dual Room 2 vDC

Vous commandez deux vDC, un dans chaque salle. Cette configuration vous permet de choisir la localisation de vos VM.

La résilience du service reposera sur les mécanismes applicatifs (mode cluster des VM, ferme de serveurs configurée dans le Load Balancer, etc.)

Vous devrez gérer la capacité de chaque vDC, car ils sont totalement indépendants en termes de ressources matérielles.

Les réseaux peuvent être partagés entre les 2 vDC.

Les tarifs One Room s’appliquent.

Cette configuration est disponible pour toutes les classes de performance.

HA Dual Room (aka HADR)

Dans cette configuration, les ressources de calcul et de stockage sont étendues sur les deux salles, fournissant ainsi la très haute disponibilité de l’infrastructure (calcul + stockage). C’est ce qu’on appelle le HADR (High Availability Dual Room)

Pour activer cette configuration, vous devez commander un seul vDC en mode Dual Room (les tarifs vDC en HA Dual Room s’appliquent).

Le stockage commandé sera automatiquement provisionné en mode Dual Room,

Le stockage est écrit simultanément sur les deux salles (RAID 1) et est toujours disponible même en cas de perte d’une salle. Les VM localisées dans la salle défaillante redémarreront automatiquement sur les ESXi de la seconde salle, et retrouveront leur stockage.

Cette configuration est disponible uniquement pour les classes de performance Standard et High Performance.

Fosuc sur PayG versus Allocation Pool

Aperçu

Les modèles de facturation des vDC s’appuient sur des modes d’allocation et de gestion des ressources de calcul paramétrées au niveau de l’hyperviseur vmware. Ces modes sont les suivants :

– PAYG

– Allocation Pool

PAYG

C’est le modèle le plus couramment utilisé, lorsque les VM sont souvent arrêtées, démarrées occasionnellement. Les cas d’usage qui motiveront ce choix de modèle sont :

• les VM fonctionnant selon une saisonnalité particulière (soldes de fin d’années, calculs de fin de mois, période promotionnelle pour un site web par exemple)
• les labs, démo et prototype, à faible durée de vie
• les environnements de formation

Prenons en exemple un vDC en PAYG, dimensionné à 10 vCPU. Lors de sa création, il sera dimensionné à 22 GHz, car le paramètre vCPU Speed est positionné par défaut à une valeur identique à celle des processeurs physiques, soit 2,2 GHz dans notre cas.

Dans notre exemple, nous avons 4 VM : 3 VM avec 2 vCPU et 1 VM avec 4 vCPU. En PAYG, il est nécessaire de dimensionner suffisamment les VM pour être sûr qu’elles auront les ressources nécessaires au moment où elles en auront besoin.

Quels que soient les besoins réels des VM en puissance de calcul (GHz), elles ont une allocation définie qui est fixe par VM, et qui dépend des paramètres choisis dans leur configuration.

Par exemple, un VM qui héberge une base de données sera dimensionnée avec 4 vCPU afin de tenir la charge en cas de forte activité de l’application, même si l’application fonctionne à 20% de charge CPU 99% du temps.

Ainsi, le dimensionnent des VM est prépondérant par rapport au dimensionnement du vDC.

Allocation Pool

C’est le modèle à privilégier lorsque la majorité des VM est allumée en permanence. Outre l’optimisation des ressources consommées, le modèle est financièrement plus intéressant.

Prenons maintenant en exemple un vDC en Allocation Pool, dimensionné à 18 GHz. Le paramètre vCPU Speed, positionné à 1,8 GHz, détermine le nombre de vCPU que le vDC pourra démarrer, soit ici 10 vCPU.

Pour cet exemple, nous gardons nos 4 VM il est nécessaire de dimensionner suffisamment les VM pour être sûr qu’elles auront les ressources nécessaires au moment où elles en auront besoin. Par contre, les ressources sont allouées au niveau du vDC (et non plus au niveau de chaque VM en PAYG), donc les VM vont pouvoir consommer les GHz qui ne sont pas utilisés par les autres VM.

Sur ce principe, le dimensionnement du vDC doit prendre en compte :

• le nombre de vCPU que l’on souhaite pouvoir démarrer
• le nombre de GHz que l’on souhaite fournir à l’ensemble des VM, sachant qu’elles ne vont pas consommer tous les GHz en permanence.

Ce mécanisme permet d’avoir toujours une réserve de GHz disponible pour des VM qui auraient de gros besoins.

A noter que le vDC en Allocation Pool utilisant mieux les ressources GHz, il n’est pas nécessaire de le dimensionner autant qu’en PAYG.

Ainsi, le dimensionnent du vDC est prépondérant par rapport au dimensionnement des VM.

---