Comment utiliser l'automatisation pour une gestion plus précise du cloud privé

Un nombre croissant d'organisations investissent dans des centres de données virtualisés et automatisés et des clouds privés. Ce n'est peut-être pas surprenant si l'on considère le coût d'infrastructure inférieur, la plus grande agilité et la meilleure sécurité qu'ils offrent par rapport aux architectures client-serveur traditionnelles ou aux clouds publics.

Ces avantages peuvent aider les secteurs d'activité à tirer parti de nouvelles opportunités, à répondre aux demandes des clients et à prendre une longueur d'avance sur leurs concurrents.

Cependant, pour éviter les retards dans le déploiement du cloud privé, il est important que les organisations accordent la priorité à un investissement dans un contrôle de réseau évolutif et automatisé. Alors que le serveur et les éléments de stockage dans un cloud privé peuvent être largement automatisés, il est probable que le réseau correspondant sera provisionné et configuré manuellement.

Un service informatique passera par une série de phases à mesure que son infrastructure de cloud privé mûrit, dont la première consiste à piloter des projets. Ici, l'équipe informatique utilisera des applications et des charges de travail non critiques pour tester la conception et l'infrastructure de son cloud.

> Voir aussi :Qu'on le veuille ou non, les données critiques sont menacées dans le cloud

Cela leur permettra non seulement de gagner en confiance et en expérience, mais également d'apporter les modifications nécessaires avant de passer à la deuxième phase de production, lorsqu'une ou un petit nombre de charges de travail critiques sont déplacées vers le cloud.

Enfin, après tout autre ajustement nécessaire, l'initiative sera entièrement déployée, impliquant éventuellement des environnements cloud géographiquement dispersés dans plusieurs centres de données et s'exécutant sur des plates-formes cloud multifournisseurs.

Gérer les risques

Chacune de ces phases peut s'avérer risquée. Quelles que soient la taille et l'échelle de l'initiative, si le déploiement n'est pas correctement synchronisé tout au long du processus, il est peu probable qu'il se déroule sans heurts.

Par exemple, les groupes disparates traitant du cloud privé peuvent présenter un défi majeur.

Bien que l'équipe du serveur puisse être responsable du composant de virtualisation, tous les aspects du réseau peuvent être entièrement gérés par une équipe différente. Par conséquent, l'équipe réseau peut manquer de visibilité sur les ressources des machines virtuelles (VM) au fur et à mesure de leur création et de leur destruction, ce qui rend difficile leur association à des tâches d'installation et de configuration automatisées.

Sans cette visibilité, il est inutile que les équipes réseau tentent même de se conformer aux politiques d'audit et de sécurité, étant donné qu'elles ne disposeront pas d'informations précises sur les adresses IP et les enregistrements DNS attribués à quelles machines virtuelles à un moment donné.

De nombreux facteurs tels que les applications, les emplacements et les utilisateurs doivent être suivis pour les machines virtuelles et les réseaux, les adresses IP et les zones DNS. La plupart des administrateurs de serveur auront accès à ces informations, mais il est probable que les équipes réseau n'y auront pas accès.

Leurs réponses auront donc tendance à être lentes en raison de l'utilisation de méthodes manuelles pour la création et la suppression de VM.

Tenir la promesse d'une livraison rapide

Un cloud privé ne peut être aussi rapide que son composant le plus lent. La promesse d'une livraison rapide, sans doute l'un des principaux attraits du déploiement du cloud privé, peut être entravée par le temps nécessaire pour provisionner manuellement les enregistrements DNS et les adresses IP dans un environnement virtuel. Ce processus peut souvent être inexact et inefficace, et peut entraîner une prolifération d'adresses IP et d'enregistrements DNS inutilisés.

La possibilité d'une panne de réseau potentiellement coûteuse causée par des services de gestion des adresses DNS, DHCP et IP non fiables - collectivement connus sous le nom de DDI - peut constituer une menace importante pour toute organisation, les risques s'étendant au-delà du réseau lui-même.

Il est possible que des inexactitudes entraînent une facturation erronée des principaux clients internes - et un préjudice compréhensible - si les adresses IP des machines virtuelles étaient utilisées à des fins de facturation. Et quelques simples frappes erronées pourraient entraîner des conflits d'adresses IP potentiels qui, à leur tour, pourraient entraîner des temps d'arrêt importants dans l'environnement de cloud privé.

> Voir aussi :Le grand mythe de l'informatique :le cloud est-il vraiment moins sécurisé que le sur site ?

Les services DDI hautement disponibles sont essentiels pour les clouds privés exécutant des charges de travail critiques ou couvrant plusieurs emplacements géographiques différents, leur fournissant l'évolutivité et la résilience dont ils ont besoin pour fonctionner efficacement.

Et à mesure que les entreprises se tournent vers l'avenir, elles peuvent constater que les limites de l'évolutivité de leur réseau peuvent entraver le déploiement des locataires et des machines virtuelles supplémentaires nécessaires pour répondre aux demandes imposées par leur croissance.

Principes d'automatisation, d'intégration et de visibilité

Le succès d'une organisation dans le déploiement d'un cloud privé dépend en grande partie de sa compréhension et de la prise en compte urgente de facteurs critiques tels que ceux mentionnés ci-dessus.

Adopter une approche basée sur les principes d'automatisation, d'intégration et de visibilité aidera une organisation à contrôler plus efficacement son déploiement de cloud privé.

Source :Arya Barirani, vice-présidente, Marketing produit, Infoblox