Partager via

SQL Server : protéger les données à tout prix

  • Article

Assurer une grande disponibilité des banques de données d’entreprise gérées avec SQL Server est un élément essentiel de toute stratégie de gestion des données.

Paul S. Randal

Sans la capacité permanente de stocker et restaurer des données, l'entreprise serait paralysée. Outre les ressources humaines d'une entreprise, les données représentent son atout le plus important. SQL Server 2008 ou SQL Server 2008 R2 sont bien souvent au cœur de toute stratégie de gestion de données. Ainsi, en considérant les choses sous cet angle, les développeurs et les administrateurs de bases de données sont responsables de la bonne marche de l'entreprise.

Toutefois, quelle est la part des orientations définitives qui filtrent des responsables d'unités opérationnelles vers ceux en charge des couches de données ? Les besoins de l'entreprise sont-ils clairement communiqués ? Sont-ils communiqués de manière à pouvoir être traduits en termes de stratégie productive par les professionnels des technologies ?

Sur certains segments de marché, il existe des exigences strictes en matière de réglementation au niveau des aspects de l'infrastructure, comme l'audit de sécurité, le chiffrage et la conservation des données. Tout manquement à ces exigences peut avoir pour conséquence une amende ou une censure de l'entreprise, sans parler de la perte de crédibilité après du public et de chiffre d'affaire à l'avenir (la pire chose qui puisse se produire dans un marché hautement concurrentiel).

Alignez votre stratégie de gestion des données

Certains besoins de l'entreprise semblent plus faciles ou plus simples à communiquer pour les responsables d'entreprise, comme ceux qui concernent la sécurité, les rapports, la gestion de la charge de travail et l'audit. Heureusement, ceux-ci sont également plus faciles à implémenter dans l'environnement de SQL Server 2008 :

  • Concernant la sécurité des données, il est possible de répondre aux besoins à l'aide de fonctionnalités telles que le chiffrement de données transparent, qui se charge de chiffrer les données aux repos, et la gestion des clés extensibles, qui permet de stocker des clés de chiffrage dans un autre emplacement, loin des données chiffrées.
  • SQL Server Reporting Services permet de répondre aux besoins au niveau des rapports.
  • Le gouverneur de ressources peut vous aider à prévoir les performances en termes de charge de travail.
  • La fonctionnalité d'audit de SQL Server peut être utilisée pour satisfaire les besoins en audit détaillé.

Cependant, deux besoins essentiels de l'entreprise sont souvent mal communiqués : l'interruption du système et les pertes de données acceptables. Ces besoins sont respectivement appelés objectif de temps de récupération (RTO) et objectif de point de restauration (RPO). Malheureusement, la réalité montre que les responsables d'entreprise négligent souvent de prendre le RTO et le RPO en considération jusqu'au moment où un incident se produit, menant à une interruption ou à une perte de données. Ils réalisent alors que la couche de données n'est pas protégée comme ils l'auraient souhaité.

Que vous soyez responsable d'entreprise ou administrateur de bases de données, prenez une minute pour répondre à cette question : la couche de donnes est-elle protégée comme les besoins de l'entreprise l'exigent ? Si vous répondez par la négative, quel est votre plan pour résoudre le problème ?

La panique ou la complaisance ne constituent pas des réactions appropriées. L'alerte incendie consistant à mettre en place une stratégie pour la semaine prochaine est la recette idéale pour courir au désastre. La conception et l'implémentation d'une stratégie appropriée de haute disponibilité et de récupération après incident (HA/DR) avec SQL Server nécessite effort et assiduité. Ignorer le problème conduit au désastre et est équivalent à de la négligence au niveau de l'entreprise.

Travailler selon les besoins

La clé pour une conception de stratégie réussie passe avant tout par un travail sur les besoins de l'entreprise. Ensuite, il s'agit de les mettre en face des limites que l'entreprise impose. C'est à cette étape que les informaticiens et les responsables d'unités opérationnelles doivent se rencontrer et se confronter. Les exigences stratégiques doivent encapsuler les facteurs suivants pour chaque partie des données adéquate aux opérations de l'entreprise :

  1. quel est le degré d'importance de cette partie des données par rapport au reste du magasin de données de l'entreprise ? Les responsables d'entreprise affirment souvent que tout est prioritaire et doit être protégé de la même manière. Ce raison fonctionne avec un petit volume de données, mais cela devient irréalisable à mesure que le nombre de téraoctets s'accroît sur des instances de serveurs SQL elles-aussi en augmentation.
  2. Quelle quantité de données l'entreprise peut-elle se permettre de perdre ? Les propriétaires d'entreprises aimeraient, et c'est compréhensible, qu'aucune donnée ne soit perdue. Cela n'est pas toujours réalisable dans les faits.
  3. Combien de temps les données peuvent-elles être indisponibles ? Les propriétaires d'entreprises aimeraient également qu'aucune interruption de service ne soit rencontrée. Cela n'est malheureusement pas un objectif réalisable. Il est toutefois possible de s'en approcher.
  4. Les facteurs un et deux sont-ils soumis à des changements à différentes heures de la journée ou pendant le week-end ? La réponse à cette question peut avoir des répercutions profondes sur votre capacité à répondre aux exigences. L'absence d'interruption et de perte de données constitue un objectif beaucoup plus réalisable sur une courte période (par exemple entre 9h et 17h les jours de semaine) que sur un accès de type 24h/24 et 365 jours par an.
  5. Est-il acceptable de sacrifier de la performance au niveau charge de travail pour préserver la disponibilité et la durabilité des données ? Les seules technologies capables d'atteindre zéro perte de données nécessitent la mise en miroir synchrone des enregistrements des journaux de transaction ou des écritures de sous-système E/S. Ces deux tâches peuvent conduire à un délai au niveau du traitement. Il s'agit d'un compromis.

Une bonne façon de les envisager est de considérer l'impact que chaque partie des données inaccessible ou perdue à sur l'entreprise. Vous pouvez être surpris lors de l'analyse en détail et lors de la quantification des conséquences potentielles pour vos clients, l'image de votre entreprise et les contrôles de réglementation auxquels vous pouvez être soumis.

Travailler selon les facteurs limitant

Une des erreurs les plus communément commises, lors de la conception et de l'implémentation d'une stratégie HA/DR, est de se lancer dans la conception technique sans, au préalable, prendre en considération les facteurs limitant. Ceci a pour conséquence le retour à la planche à dessin (une perte de temps et d'argent) ou l'implémentation d'une stratégie de moindre qualité qui ne respecte pas les exigences de l'entreprise.

Il existe de nombreuses limites, à la fois techniques et non techniques. Le facteur principal est généralement le budget. Plus de matériel implique plus de puissance électrique, ce qui veut dire plus de dissipation de chaleur, donc plus de conditionnement de l'air, entrainant encore plus de puissance, le tout prenant plus d'espace et plus de budget alloué à cette infrastructure physique. Le coût du matériel, les licences SQL Server et Windows supplémentaires, la bande passante pour le réseau, et peut-être même un besoin plus important en personnel pour gérer les systèmes supplémentaires et le reste du centre de données, sont des éléments à prendre en compte.

Compromis et casse-tête de l'entreprise

Une fois que les limites techniques vous sont familières, la difficulté est d'atteindre le compromis le plus efficace. Une liste des données les plus importantes pour l'entreprise, classées par ordre de priorité, est nécessaire. Selon les limites auxquelles votre travail est soumis, vous évaluerez les technologies qui vous aident à répondre aux exigences les plus importantes pour l'entreprise.

Il est essentiel de ne pas se contenter d'essayer d'adapter une technologie existante pour répondre aux exigences de l'entreprise. Ne vous précipitez pas ni ne choisissez sur une technologie sans la confronter réellement aux priorités de votre entreprise. Il est toujours préférable de produire l'effort au tout début et de poursuivre le processus dans de bonnes conditions. Au final, vous obtenez une meilleure stratégie qui vous permet de gagner du temps et de l'argent à long terme.

S'il s'avère que les technologies dans lesquelles vous pouvez vous permettre d'investir ne permettent pas de répondre aux exigences de l'entreprise, il sera alors nécessaire de travailler avec les responsables d'unités opérationnelles pour modifier ces exigences en cohérence avec les réalités budgétaires. Par exemple, un technicien n'a aucun intérêt à être d'accord avec une exigence d'entreprise cherchant à atteindre zéro perte de données si le budget ne permet pas d'investir dans les technologies synchrones. Lorsqu'un incident se produira, les attentes des responsables de l'entreprise ne seront pas satisfaites, et la faute incombera au personnel des services informatiques.

L'une des plus grandes difficultés, lors de la conception d'une stratégie HA/DR, est souvent de s'assurer qu'elle s'inscrit de façon harmonieuse dans la stratégie informatique globale de l'organisation. Par exemple, si vous êtes l'administrateur des bases de données au sein d'une grande entreprise, les serveurs, le réseau, le stockage, l'infrastructure des bâtiments, etc., sont probablement la responsabilité d'autres équipes. Si l'entreprise demande qu'une base de données particulière soit disponible sous quatre heures suite à un incident, il est probable que vous deviez impliquer toutes ces équipes pour vous assurer que cela puisse être le cas. Cette constatation implique une politique et des relations d'échange entre les équipes. Les autres équipes doivent accepter de satisfaire les mêmes accords de niveau de service que l'équipe en charge de la couche de données, ainsi que les attentes et les promesses de l'entreprise dans son ensemble.

Test, test

Si vous avez le sentiment que la couche de données n'est pas protégée de manière adéquate, il est probable que la stratégie HA/DR n'a pas été correctement testée dans l'entreprise. À mesure que vous progressez dans la conception et l'implémentation d'une stratégie HA/DR, il est impératif de véritablement tester le système pour qu'il puisse répondre en cas de crise.

Ceci étant, c'est plus facile à dire qu'à faire. Convaincre les responsables d'entreprise de mener un test susceptible d'engendre une interruption de service est un défi. L'argument peut être qu'il est préférable de mener un test pendant que tout le monde est présent sur site, de s'attendre à un incident et d'être prêt à faire face et à rapidement résoudre tout problème. L'alternative peut être de découvrir une conception défectueuse lors d'un incident se produisant à 2 heures du matin, un jour férie, lorsque l'équipe présente est réduite à peau de chagrin.

Bien que vous puissiez vous rendre compte que votre couche de données n'est pas protégée des interruptions de service et de la perte de données selon un niveau acceptable, il existe de nombreuses solutions pour l'implémentation d'une stratégie HA/DR à l'aide de SQL Server 2008 ou de SQL Server 2008 R2. Il s'agit de comprendre les différentes technologies et leurs compromis, et d'examiner les architectures que d'autres entreprises ont réussi à déployer. Consultez les documents techniques et les billets de blogs suivants pour plus d'informations :

Assurez-vous que votre travail conduise à mettre en place une stratégie valide. C'est la seule façon de protéger votre entreprise et d'éviter des interruptions de service inattendues.

Paul Randal

Paul S. Randalest directeur général de SQLskills.com, directeur régional Microsoft et MVP SQL Server. Il a travaillé sur le moteur de stockage de données de SQL Server chez Microsoft de 1999 à 2007. Il a écrit DBCC CHECKDB/repair pour SQL Server 2005 et était responsable de Core Storage Engine pendant le développement de SQL Server 2008. Expert de la récupération d'urgence, de la haute disponibilité et de la maintenance de base de données, il anime fréquemment des conférences. Vous trouverez son blog à l'adresse SQLskills.com/blogs/paul et sa page Twitter à l'adresse twitter.com/PaulRandal.

Contenu associé