Comment l'automatisation améliore la précision dans la gestion du cloud privé

Un nombre croissant d'organisations investissent dans des centres de données virtualisés, automatisés et des clouds privés. Cela n'est guère surprenant quand on considère les coûts d'infrastructure inférieurs, l'agilité accrue et la meilleure sécurité qu'ils offrent par rapport aux architectures client-serveur traditionnelles ou aux clouds publics.

Ces avantages peuvent aider les lignes métier à capitaliser sur de nouvelles opportunités, répondre aux demandes des clients et prendre une longueur d'avance sur leur concurrence.

Cependant, pour éviter les retards dans le déploiement du cloud privé, il est important que les organisations priorisent un investissement dans un contrôle réseau automatisé et évolutif. Bien que les éléments serveur et stockage dans un cloud privé puissent être largement automatisés, il est probable que le réseau correspondant soit provisionné et configuré manuellement.

Un service IT traversera une série de phases à mesure que son infrastructure de cloud privé mûrit, la première étant les projets pilotes. Ici, l'équipe IT utilisera des applications et charges de travail non critiques pour tester la conception et l'infrastructure de leur cloud.

Voir aussi : Qu'on le veuille ou non, les données critiques SONT en danger dans le cloud

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

Enfin, après d'autres ajustements nécessaires, l'initiative sera pleinement déployée, impliquant éventuellement des environnements cloud géographiquement dispersés dans plusieurs centres de données, et fonctionnant sur des plateformes cloud multi-fournisseurs.

Gérer les risques

Chacune de ces phases peut s'avérer risquée. Quelle que soit 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 gérant le cloud privé peuvent présenter un défi majeur.

Alors que l'équipe serveur peut être responsable du composant de virtualisation, tous les aspects réseau peuvent être gérés par une équipe entièrement différente. En conséquence, l'équipe réseau peut manquer de visibilité sur les ressources des machines virtuelles (VM) au fur et à mesure qu'elles sont créées et détruites, rendant difficile le lien de ces ressources aux tâches de configuration et de mise en place automatisées.

Sans cette visibilité, il y a peu d'intérêt pour les équipes réseau à tenter de se conformer aux politiques d'audit et de sécurité, étant donné qu'elles n'auront pas d'informations précises sur les adresses IP et les enregistrements DNS attribués à quelles VM à un moment donné.

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

Leurs réponses seront donc lentes en raison d'une dépendance aux méthodes manuelles pour la création et la suppression des 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'une des principales attractions du déploiement de cloud privé, peut être entravée par le temps qu'il faut 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 réseau potentiellement coûteuse causée par des services DNS, DHCP et de gestion d'adresses IP peu fiables — collectivement connus sous le nom de DDI — peut poser une menace significative pour toute organisation, les risques s'étendant au-delà du seul réseau.

Il est possible que des inexactitudes entraînent une facturation erronée de clients internes clés — et compréhensiblement mécontents — si les adresses IP des VM étaient utilisées à des fins de facturation. Et quelques frappes erronées simples pourraient entraîner des conflits d'adresses IP potentiels qui, à leur tour, pourraient causer un temps d'arrêt significatif dans l'environnement de cloud privé.

Voir aussi : Le grand mythe IT : le cloud est-il vraiment moins sécurisé que l'on-premise ?

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

Et alors que les organisations regardent vers l'avenir, elles peuvent découvrir que les limites de l'évolutivité de leur réseau peuvent entraver le déploiement des locataires et VM supplémentaires nécessaires pour répondre aux exigences que leur croissance dicte.

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 largement de sa compréhension et de l'attention urgente qu'elle porte à des 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 à prendre un contrôle plus efficace de son déploiement de cloud privé.

Propos d'Arya Barirani, VP, Marketing Produit, Infoblox