Le Post Infeeny

Les articles des consultants et experts Infeeny

[SQL] Real-World System Design for the DBA : Private Cloud ans SQL as a Service

Bon aujourd’hui on part sur le Private Cloud  et SQLaaS comprenez SQL As A Service.

Autant dire des sujets que je ne connais pas du tout. On dirait qu’il y a beaucoup de DBA dans l’assistance (des vieux barbus avec des chemises de bucherons) et oui les mythes ont la peau dure.

Speakers : Alln Hirt Clustering & Ben DeBow de SQLHA – Niveau : 200

Introduction

Cette session à pour but de comptrendre comment planifier, deployer et maintenir une plateforme SQL Server en fonction des besoins et des exigences métiers de votre entreprise.

La ligne directrice

Le métier se moque de savoir comment le système fonctionne et les contraintes techniques, tout ce qu’ils veulent et qu’ils jugent est le résultat…

Les promesses du cloud

  • Accessible partout et n’importe quand
  • Plus à s’occuper de la disponibilité des backups ni d’aucune autre opération d’admin (y compris les upgrades)

Qu’est ce que le cloud pour l’IT

Le cloud privé = à vous de gérer les services (au niveau software bien sûr) pour répondre aux besoins.

  • Plus sécurisé
  • Plus couteux mais vous pouvez tout contrôler
  • Personnalisation de la solution afin de « fitter » au mieux avec les attentes business

Le cloud public = utilisation de briques « génériques » pour répondre aux besoins

  • Moins sécurisé
  • Moins contrôlable
  • Coût raisonable
  • Générique mais flexible
  • Peu être facilement « spinup » mais plus difficile à maintenir

Pour matcher avec les attentes utilisateurs, on peut être ammené à mixer les deux. La règle d’or reste celle vue sur la ligne directrice : peu importe votre solution, elle doit être transparente pour le business et répondre aux attentes métiers.

SQL Server as a Service

On commence par quelques considérations qu’il est toujours bon de rappeler

1.       Ne pas voir SQLaaS simplement comme une solution technique. Afin d’avoir un service optimum et de mettre en place la bonne solution en place, il faut connaitre tous les facteurs :

  • Criticité
  • Business
  • Technique

2.       S’imprégner et récupérer toutes les informations de situation actuelle

a.       Récupérer les process déjà définis

  • RTO : Recovery Time, c’est le temps maximal d’indisponibilité d’une application ou d’un système
  • SLA : Service Level Agreement, ce chiffre découle du RTO mais sur une base annualisée (temps d’indisponibilité total / temps total annuel)
  • RPO : Recovery Point Objective, c’est la quantité maximale de données perdues tolérée en cas de problème

b.      Comprendre les ressources et l’architecture déjà en place (Serveurs, instances, bases de données, configurations, les équipes d’admin et leurs niveaux)

En conclusion : rien ne sert de réinventer la roue, vous pouvez réutiliser ce qui a déjà été définit, sans oublier de réviser les solutions en place afin de déterminer si elles doivent être mises à jour ou complètement revues.

N.B : pour des définitions plus précises sur les termes RTO,SLA et RPO je vous renvoie vers le blog de Christian Robert ici

Récupérer les infos de l’architecture actuelle

Pour récupérer toutes les infos de notre architecture actuelle, on utilise un outil bien pratique dénommé « Microsoft Assesment and Planning toolkit » (MAP) son petit nom vous dit certainement quelque chose. Ce dernier permet de faire un inventaire et de récupérer ainsi tous les métriques de votre architecture (serveurs, disques, services, virtualisation ….) . Une fois les infos collectées et organisées, nous pouvons les visualiser et les analyser sous Excel (bien sûr avec Excel 2013 c’est beaucoup plus sympa 😉 ) :

  • Répartition des instances  par type de SBDGR
  • La ventilation par type d’environnement (dev/recette/prod) et de SGBDR du nombre d’instances, nombre de cœurs, la taille de bases …
  • Stats d’utilisation des serveurs

Eh mais on fait de la BI là …

Prise en compte des problématiques métiers

Avant toute chose, vous devez

  • Comprendre le métier
  • Prendre en compte les contraintes politiques
  • Comprendre les facteurs de coûts

La clé du succès est de comprendre la situation actuelle et de connaître l’intégralité des attentes

  • Faites du top down et non du bottom up
  • Faites des plans à court, moyen et long terme

Premières choses à mettre en place :

1.       Sécuriser le projet :

o    trouver des sponsors à l’exécutif,

o    budgéter le projet (un budget macro dans un premier temps peu suffire pour démarrer)

2.       Monter un comité pour

o    rassembler différents métiers

o    définir les lignes principales : SLA, les exigences de base des métiers

3.       S’assurer que les métiers aient du temps à dédier sur le sujet

4.       Quel est votre ROI ? Il est important de communiquer dessus, la fin doit justifier les moyens !

Les questions à se poser

Reconnaitre ce que vous ne connaissez pas. En fonction du scope du projet ou de vos compétences, vous ne pourrez peut-être pas tout gérer tout seul, est-il temps de prendre un consultant pour vous aider?

Comment arriverez-vous à votre état final en fonction de :

  • des technologies actuellement déployées
  • de la taille du scope d’intervention (plus grand/plus petit, le même) que celui attendu
  • des contraintes de temps
  • des contraintes budgétaires

Ne négligez pas la documentation et l’importance de vos analyses.

Tout ce que vous avez collecté et analysé doit être rapidement accessible.

Faites un résumé des informations clés pour chaque métier :

  • Les plans techniques détaillés n’intéressent pas vos interlocuteurs métiers
  • Plus c’est court, mieux c’est. En règle générale, des diagrammes ou des schémas sont plus explicites

Appliquez la règle des 90%, ne concevez pas votre solution pour gérer toutes les exceptions.

Les principes clés à prendre en compte lors de la conception

  • Facilité de déploiement : prévoir du self-service ou des procces onboarding ? (à reprendre)
  • Facilité de maintenance : ce fait elle via l’application et un key user ou bien est-elle centralisée par l’IT ?
  • Utiliser les ressources au maximum sans les surcharger
  • Flexibilité, les choses changent tout le temps, il faut que votre architecture puisse s’adapter le plus rapidement
  • L’objectif est d’accroitre la productivité de l’entreprise en diminuant les coûts

Adopter une approche à plusieurs niveaux

Offrir plus de performance, de disponibilité, de services doit avoir du sens pour votre société. Sachez que

  • vous ne pouvez satisfaire tout le monde
  • et que le changement n’est pas toujours facile pour les utilisateurs.

Comment piloter la conception ?

  • Par les coûts
  • Par le business
  • Par les facteurs techniques
  • Par tous les points vus précédemment

D’un point de vue technique, la conception SQLaaS doit prendre en compte toutes les considérations :

  • Storage
  • Networking
  • Servers
  • OS
  • SQL Configuration
  • Administration
  • Lifecycle management

Le temps de faire une petite pause déjeuner et on reprend.

Voyons désormais comment se passe le design d’une plateforme SQLaaS

Overview SQLSaas

On distingue trois stack :

  • Infrastructure Services : la techno sur laquelle on va s’appuyer
  • SQL Services : les services SQL  que nous allons exposer (audit, sécurité, monitoring, stratégie de backup, santé, performance tuning, db maintenance)
  • Management : les services permettant de gérer les ressources (allocation de ressources, management de configurations, Self-Service, Chargeback, opérations, access control, gestion des patch/du changement)

La technologie utilisée

Il faut définir la ou les plateformes cibles :

  • Vendeurs Hardware
  • Plateformes et versions (OS, DV virtualization)
  • D’autres soft et technos (backup, sécurité, antivirus, monitoring)

N.B : attention lors de cette étape tout est lié. Par exemple, le nombre de sockets/cœurs peut influencer le coût des licences ou limiter l’évolutivité. Par conséquent, les décisions prises maintenant auront des effets sur le long terme ; de mauvaises décisions peut-être très couteuses et vous limiter par la suite. La meilleure solution reste de prendre les décisions en fonction des faits.

Choix de la plateforme

  • Choix de l’OS
  • Faites un POC. Comme toute maquette, commencez petit et enrichissez au fur et à mesure. Testez en premier lieu l’architecteur puis, enfin, les performances.
  • Faites des tests de charge

o    Combien de transaction par seconde peuvent être traitées par ma plateforme ?

o    Si la charge de travail ou les ressources sont modifiés, comment cela va –t’il affecter les transactions ?

  • Testez différents scénarios de charge de travail, identifier les services qui peuvent être exécutés en parallèle.
  • Essayez différentes configurations car il est difficile d’effectuer ces modifications une fois en production

o    Densité des VM

o    Configurations de LUN

o    ROW/PAGE compression

o    Mixer les tailles des VM

o    NUMA, hyperthreading, mémoire

Le choix physique/virtuel

Le duel Cornélien…

Sachez que la virtualisation est une option viable pour SQL Server car évolutive et permettant de stocker d’important volumes de données.

Dans la majorité des environnements on mixe du physique avec du virtuel (ne jamais partir sur la politique du tout ou rien)

Ce qui va vous permettre de choisir sont les points suivants

  • Les ressources ne doivent jamais être surchargées (surtout sur les VMs)
  • Les coûts de licences
  • La capacité de surveillance et de dépannage
  • Les outils d’admin

Si vous partez sur un serveur physique vous devrez trancher entre un big iron, 1U, Blades, il faudra prendre en comptes les coûts et faire des compromis

Si vous partez sur un serveur virtuel : il vous faudra choisie la plateforme plus adaptée (Hyper-V, VMWARE, …)

N.B : notez que l’option choisit va influencer votre design comme par exemple un ou plusieurs instance  SQL sur un serveur. En effet, sur un serveur physique avec plusieurs instances, le chargeback mémoire sera plus compliqué que si nous avions une instance par VM.

Comparer le coût de votre plateforme par rapport à celui des appliances ou bien au coût de votre plateforme hébergée chez un tiers.

Le Stockage

Le sizing est important il est crucial de prendre en compte les problématiques d’I/O, et de Perf Vs Disponibilité Vs Capacité

Il doit être effectué sur chacun de vos environnements (dev, recette, prod)

Le réseau

Les questions à se poser :

  • Si vous avez besoin de Fail Over Clustering ou d’Always On, cela peut avoir des impacts sur votre infrastructure réseau
  • IP V6 ou non ?
  • Réseau dédié pour les backups ?
  • Sous-réseaux multiples ?

Demos tests Hardware

On passe sur quelques tests hardware

L’environnement est le suivant :

  • ESX4
  • Win 2k8R2
  • SQLS 2K8R2
  • Apps : TPC-C, TPC-H, Db Backup & Batch
  • Sous-système disque (I/O) : SAN

Les différents serveurs testés sont les suivants :

  • IBM X3850 X5 32 cœurs 256GB
  • Cisco UCS Bale 12 cœurs 384 GB
  • HP DL 380 8 cœurs 72 GB

On monte des VMs dessus avec des configurations équivalentes (16 Go de RAM, 2 CPU, 1 disque pour l’OS de 40 Go, un disque de données de 680 Go)

On fait des tests d’isolation OS sur trois scénarios de workload:

  • Batch
  • TPCC
  • TPCH

Et on récupère les métriques suivants Avg IOPS, Avg Disk Reads/sec, Avg Disk Writes/sec, MAS SQL Server memory, # TPS.

On compare les résultats des différents systèmes.

On s’amuse ensuite avec quelques modifications de configuration :

1.       sur les backups (sans et avec compression) et on analyse la conséquence de cette option sur les différentes plateformes. Le CPU est plus sollicité avec la compression mais les I/O sont réduits.

2.       sur la compression de données (Row Vs Page Compression). On constate que la Row Compression donne de meilleures performances que le Page Compression sur le nombre de transactions par seconde TPS.

3.       Sur les incidences de choix réseaux Server TX vs Uplink TX  (en attaquant directement la carte réseau du serveur ou en passant par un switch)

Cela nous permet de voir l’importance des tests de charges et de configuration afin de choisir la plateforme la mieux adaptée en fonction de vos besoins.

Haute disponibilité et disaster revory

On repasse ensuite sur les problématiques de haute disponibilté et de Disaster Recovery

Assurez-vous pour chacun de ces sujets d’en avoir besoin.

Faites attention aux applications présentes dans votre parc, toutes ne supportent pas ces fonctionnalités.

Privilégier la Performance ou la Disponibilité

Les deux sont importants, essayez de

  • Quels sont les préférences du métier à ce sujet en fonction de la criticité des services exposés ?
  • Assurez-vous que le métier comprend la différence entre ces 2 notions.

Ces deux notions vont avoir leurs incidences sur les coûts et la complexité de votre plateforme.

Sécurité

L’important est de savoir ce que chacun veut faire afin de pouvoir lui appliquer les droits adaptés à son besoin:

Ici un exemple de rôles : dba, application, operateur, développeur, utilisateur,  ….

Les applications permettant de manager vos services

Il est important d’avoir une liste exhaustive des outils vous permettant d’effectuer le chargeback sur les métriques que vous voulez suivre.

Il se peut que vous ayez pour un même métrique, différents outils vous permettent d’effectuer le chargeback. A vous d’identifer les overlap et de choisir le composant que vous utiliserez.

Demo Hyper-V

On passe désormais sur la création d’une machine virtuelle sur Hyper-V et sur l’importance de bien paramétrer les priorités de vos différentes VMs (toujours en fonction des besoins et de la criticité des certaines applications par rapport à d’autres).

Frédéric

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s

%d blogueurs aiment cette page :