Bonjour à tous !!!
Voici un post qui ne devrait pas laisser indifférentes les personnes qui ont procédé au déplacement laborieux de toutes les bases d'une instance SQL, en particulier les bases système !
En effet, si le déplacement de ces bases est largement documenté dans la MSDN, il n'en demeure pas moins extrêmement long et fastidieux d'entreprendre une telle opération...
On note cependant l'effort important que Microsoft a consenti pour simplifier ce déplacement entre la version SQL Server 2000 et SQL Server 2005.
Pour mémoire, vous trouverez ici la documentation concernant le déplacement des fichiers des bases de données système de SQL Server 2000 et de SQL Server 7.
Sous SQL Server 2005, seul le déplacement des bases de données Master et mssqlsystemresource, nouvelle base de données qui n'existait pas sous SQL Server 2000, nécessite un traitement particulier.
Je vous propose donc ici un script customisable qui devrait ravir les grands et les petits qui souhaitent déplacer leurs bases de données système SQL Server 2005 en un clic !
Pour exploiter le code suivant, sauvegardez le dans un fichier Visual Basic Script (par exemple c:\movedb.vbs) et lancez le !
Function newliner(s)
newliner = Replace(s,"\n",VBCrLf)
End Function
Sub commande(s)
shcmd.Run "cmd /C " & s,1,true
End Sub
Dim base(4)
base(0) = array("ma","","","","master.mdf","mastlog.ldf")
base(1) = array("rs","mssqlsystemresource","data","log","mssqlsystemresource.mdf","mssqlsystemresource.ldf")
base(2) = array("mo","model","modeldev","modellog","model.mdf","modellog.ldf")
base(3) = array("db","msdb","MSDBData","MSDBLog","MSDBData.mdf","MSDBLog.ldf")
base(4) = array("tp","tempdb","tempdev","templog","tempdb.mdf","templog.ldf")
Function baseray(s)
baseray = array()
For Each row in base
If row(0) = s Then
baseray = row
End If
Next
End Function
' Déplace une base de données autre que "master" et "resource"
Sub movenormal(row, s)
database = row(1)
If s = "d" Then
nom = row(2)
fichier = row(4)
Elseif s = "j" Then
nom = row(3)
fichier = row(5)
End If
commande("sqlcmd -S " & instance & " -Q ""ALTER DATABASE " & database & " MODIFY FILE (name=" & nom & ", FILENAME='" & dest & "\" & fichier & "')""")
commande("net stop " & serviceinstance & " /yes")
commande("move """ & src & "\" & fichier & """ """ & dest & """ ")
commande("net start " & serviceinstance)
End Sub
' Déplace "master" et "resource"
Sub movemaster()
row = base(0)
fichierd = row(4)
fichierj = row(5)
commande("net stop " & serviceinstance & " /yes")
'SEARCH and replace parameters
cle = "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\Instance Names\SQL\" & keyinstance
cleinstance = shcmd.RegRead(cle)
cle = "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\" & cleinstance & "\MSSQLServer\Parameters"
If s = "d" Then
shcmd.RegWrite cle & "\SQLArg0", "-d" & dest & "\" + fichierd, "REG_SZ"
commande("move """ & src & "\" & fichierd & """ """ & dest & """ ")
Elseif s = "j" Then
shcmd.RegWrite cle & "\SQLArg2", "-l" & dest & "\" + fichierj, "REG_SZ"
commande("move """ & src & "\" + fichierj & """ """ & dest & """ ")
End If
commande("net start " + serviceinstance + " /f /T3608")
row = base(1)
database = row(1)
nomd = row(2)
nomj = row(3)
fichierd = row(4)
fichierj = row(5)
If s = "d" Then
commande("sqlcmd -S " & instance & " -Q ""ALTER DATABASE " & database & " MODIFY FILE (name=" & nomd & ", FILENAME='" & dest & "\" & fichierd & "')""")
commande("move """ & src & "\" & fichierd & """ """ & dest & """ ")
Elseif s = "j" Then
commande("sqlcmd -S " & instance & " -Q ""ALTER DATABASE " & database & " MODIFY FILE (name=" & nomj & ", FILENAME='" & dest & "\" & fichierj & "')""")
commande("move """ & src & "\" & fichierj & """ """ & dest & """ ")
End If
commande("sqlcmd -S " & instance & " -Q ""ALTER DATABASE " & database & " SET READ_ONLY""")
commande("net stop " & serviceinstance & " /yes")
commande("net start " & serviceinstance)
End Sub
set shcmd = WScript.CreateObject("WScript.Shell")
' Variables à redéfinir par InputBox ou manuellement:
' nom du serveur SQL et de l'instance dont on déplace les basese
serveur = InputBox("Nom du serveur")
If serveur = "" Then WScript.Quit
instance = InputBox("Nom de l'instance (Pour l'instance par défaut, laisser le champ vide)")
If Replace(instance, " ", "") = "" Then
instance = serveur
serviceinstance = "MSSQLSERVER"
keyinstance = "MSSQLSERVER"
Else
instance = serveur & "\" & instance
serviceinstance = "MSSQL$" & instance
keyinstance = instance
End If
src = InputBox("Chemin source")
dest = InputBox("Chemin destination")
line = "Base(s) à déplacer:\nmr: master + resource\ndb: msdbdata\nmo: model\ntp: tempdb\n(ex: 'mr, tp')"
db = InputBox(newliner(line))
line = "Déplacer (d)onnées, (j)ournaux\n ou les deux (d,j)"
dj = InputBox(newliner(line))
'line = "Paramêtres:\n- source: " + src + "\n- destination: " + dest + "\n- bases: " + db + "\n- objets: " + dj
'msgbox(newliner(line))
dbpar = Split(Replace(db," ",""),",")
djpar = Split(Replace(dj," ",""),",")
For Each db In dbpar
If db <> "mr" Then
r = baseray(db)
If ubound(r) > -1 Then
For Each dj in djpar
movenormal r, dj
Next
End If
Else
movemaster
End If
Next
Bonne journée !
Affichage des articles dont le libellé est Administration. Afficher tous les articles
Affichage des articles dont le libellé est Administration. Afficher tous les articles
lundi 30 juillet 2007
lundi 2 avril 2007
Maintenance des index SQL Server - Défragmentation et réindexation
Bonjour à tous !
Je rencontre de plus en plus fréquemment le problème de la fragmentation des index.
En effet, lorsqu'un fort volume de données est inséré dans une table sans que cela ne soit prévu lors de la conception de la base de données, les index croissent de manière désordonnée...
Pour détecter une telle fragmentation, SQL Server 2000 offre la commande suivante :
DBCC SHOWCONTIG
Si cette commande est toujours disponible sous SQL Server 2005 - et sera amenée à disparaitre dans les versions futures -, ce dernier fournit d'autres outils plus ergonomiques et plus précis pour les administrateurs. Parmi ces outils, on notera notamment la fonction dynamique suivante :
sys.dm_db_index_physical_stats
Il existe plusieurs façons de corriger le problème de la fragmentation. Mais avant de voir ces différentes techniques, attachons-nous tout d'abord à la façon dont l'on peut éviter que cette fragmentation ne se produise...
En réalité, tout dépend du mode d'alimentation de la base de données. En effet, un batch de chargement sera traité différemment d'une insertion unitaire.
De la même manière, le milieu fonctionnel impose des contraites ne permettant pas toujours l'emploi de certaines techniques.
Voyons tout d'abord le cas du batch de chargement : lors de l'exécution d'un batch, nous insérons généralement de grandes quantité de données. Ces batches s'exécutent habituellement de nuit, période de faible activité pour la base de données.
Dans ce cas, nous privilégierons la suppression de tous les index avant le chargement, et la recréation de ces index à la fin. Ceci présente un double avantage :
- D'une part les index regénérés ne sont pas fragmentés, puisque tout frais
- D'autre part le chargement des données est beaucoup plus rapide
Je rappellerai ici que la clé primaire incluant un index unique doit également être supprimée dans ce cas - parce que non, ça n'arrive jamais qu'il y ait des personnes qui suppriment tous les index sauf celui de la clé primaire ;-).
Bien entendu, cette suppression des index implique une absence d'activité sur la base de données sur une plage horaire donnée.
Dans le cas des insertions unitaires, le volume de ces insertions est généralement prévisible et plus faible. Dans ces conditions, le mieux est de dimensionner le FILLFACTOR de l'index à une valeur assurant un espace suffisant pour son développement.
Attention à ne pas tomber dans l'excès tout de même : un FILLFACTOR inférieur à 50 dégrade très fortement les performances et s'avère donc plus pénalisant que la fragmentation des index.
Attachons-nous maintenant à une table dont les index sont largement fragmentés.
Une solution simple reste la suppression des index pour les recréer. Cette solution présente l'avantage de toujours donner satisfaction et d'éviter l'explosion des groupes de fichiers.
Cette solution peut être effectuée dans un script traditionnel (DROP/CREATE) ou à l'aide de la commande DBCC DBREINDEX.
L'inconvénient majeur de cette méthode reste la période d'inactivité de la base de données nécessaire pour la reconstruction des index, car ces opérations sont des opérations OFFLINE.
La commande DBCC DBREINDEX, toujours présente dans SQL Server 2005, possède un équivalent avec la commande ALTER INDEX avec l'option REBUILD.
L'autre solution est la défragmentation (DBCC INDEXDEFRAG). Cette solution est une solution ONLINE. C'est la principale raison d'être de l'utilisation de cette commande. Cependant, il faut prendre garde à n'effectuer cette opération qu'après le chargement et non pas en parallèle au risque d'être totalement inefficace.
Le principal inconvénient de cette solution est la place nécessaire sur les groupes de fichiers. En effet, la défragmentation déplace des blocs de données vers des emplacements libres, et par conséquent pose rapidement des problèmes de taille des groupes de fichiers si la fragmentation est très importante. De plus la défragmentation est une opération entièrement loggée générant de fait de très gros volumes dans les journaux de transactions.
Là encore, SQL Server 2005 autorise toujours la commande DBCC INDEXDEFRAG, destinée à disparaître au profit du ALTER INDEX avec l'option REORGANIZE.
En conclusion, voici un récapitulatif des points importants :
- La première des choses est de s'assurer dans le cadre du développement de la base de données que notre base de données ne se fragmentera pas ou peu. Pour cela, il ne faut pas hésiter à supprimer les index et à les recréer au cours des processus d'alimentation. La fragmentation des index n'est pas une fatalité.
- Par la suite, un examen régulier de l'état de la base de données permet de surveiller l'évolution des index et le cas échéant d'entreprendre des actions.
- Sous SQL Server 2000, on privilégiera la commande atomique DBCC DBREINDEX si l'opération peut être menée OFFLINE. On restreindra donc l'usage de la commande DBCC INDEXDEFRAG aux cas nécessitant que les données restent ONLINE.
- Sous SQL Server 2005, on utilisera la commande ALTER INDEX avec les options REBUILD et REORGANIZE qui vont bien, cette commande étant la seule destinée à être maintenue dans les prochaines versions de SQL Server.
Je rencontre de plus en plus fréquemment le problème de la fragmentation des index.
En effet, lorsqu'un fort volume de données est inséré dans une table sans que cela ne soit prévu lors de la conception de la base de données, les index croissent de manière désordonnée...
Pour détecter une telle fragmentation, SQL Server 2000 offre la commande suivante :
DBCC SHOWCONTIG
Si cette commande est toujours disponible sous SQL Server 2005 - et sera amenée à disparaitre dans les versions futures -, ce dernier fournit d'autres outils plus ergonomiques et plus précis pour les administrateurs. Parmi ces outils, on notera notamment la fonction dynamique suivante :
sys.dm_db_index_physical_stats
Il existe plusieurs façons de corriger le problème de la fragmentation. Mais avant de voir ces différentes techniques, attachons-nous tout d'abord à la façon dont l'on peut éviter que cette fragmentation ne se produise...
En réalité, tout dépend du mode d'alimentation de la base de données. En effet, un batch de chargement sera traité différemment d'une insertion unitaire.
De la même manière, le milieu fonctionnel impose des contraites ne permettant pas toujours l'emploi de certaines techniques.
Voyons tout d'abord le cas du batch de chargement : lors de l'exécution d'un batch, nous insérons généralement de grandes quantité de données. Ces batches s'exécutent habituellement de nuit, période de faible activité pour la base de données.
Dans ce cas, nous privilégierons la suppression de tous les index avant le chargement, et la recréation de ces index à la fin. Ceci présente un double avantage :
- D'une part les index regénérés ne sont pas fragmentés, puisque tout frais
- D'autre part le chargement des données est beaucoup plus rapide
Je rappellerai ici que la clé primaire incluant un index unique doit également être supprimée dans ce cas - parce que non, ça n'arrive jamais qu'il y ait des personnes qui suppriment tous les index sauf celui de la clé primaire ;-).
Bien entendu, cette suppression des index implique une absence d'activité sur la base de données sur une plage horaire donnée.
Dans le cas des insertions unitaires, le volume de ces insertions est généralement prévisible et plus faible. Dans ces conditions, le mieux est de dimensionner le FILLFACTOR de l'index à une valeur assurant un espace suffisant pour son développement.
Attention à ne pas tomber dans l'excès tout de même : un FILLFACTOR inférieur à 50 dégrade très fortement les performances et s'avère donc plus pénalisant que la fragmentation des index.
Attachons-nous maintenant à une table dont les index sont largement fragmentés.
Une solution simple reste la suppression des index pour les recréer. Cette solution présente l'avantage de toujours donner satisfaction et d'éviter l'explosion des groupes de fichiers.
Cette solution peut être effectuée dans un script traditionnel (DROP/CREATE) ou à l'aide de la commande DBCC DBREINDEX.
L'inconvénient majeur de cette méthode reste la période d'inactivité de la base de données nécessaire pour la reconstruction des index, car ces opérations sont des opérations OFFLINE.
La commande DBCC DBREINDEX, toujours présente dans SQL Server 2005, possède un équivalent avec la commande ALTER INDEX avec l'option REBUILD.
L'autre solution est la défragmentation (DBCC INDEXDEFRAG). Cette solution est une solution ONLINE. C'est la principale raison d'être de l'utilisation de cette commande. Cependant, il faut prendre garde à n'effectuer cette opération qu'après le chargement et non pas en parallèle au risque d'être totalement inefficace.
Le principal inconvénient de cette solution est la place nécessaire sur les groupes de fichiers. En effet, la défragmentation déplace des blocs de données vers des emplacements libres, et par conséquent pose rapidement des problèmes de taille des groupes de fichiers si la fragmentation est très importante. De plus la défragmentation est une opération entièrement loggée générant de fait de très gros volumes dans les journaux de transactions.
Là encore, SQL Server 2005 autorise toujours la commande DBCC INDEXDEFRAG, destinée à disparaître au profit du ALTER INDEX avec l'option REORGANIZE.
En conclusion, voici un récapitulatif des points importants :
- La première des choses est de s'assurer dans le cadre du développement de la base de données que notre base de données ne se fragmentera pas ou peu. Pour cela, il ne faut pas hésiter à supprimer les index et à les recréer au cours des processus d'alimentation. La fragmentation des index n'est pas une fatalité.
- Par la suite, un examen régulier de l'état de la base de données permet de surveiller l'évolution des index et le cas échéant d'entreprendre des actions.
- Sous SQL Server 2000, on privilégiera la commande atomique DBCC DBREINDEX si l'opération peut être menée OFFLINE. On restreindra donc l'usage de la commande DBCC INDEXDEFRAG aux cas nécessitant que les données restent ONLINE.
- Sous SQL Server 2005, on utilisera la commande ALTER INDEX avec les options REBUILD et REORGANIZE qui vont bien, cette commande étant la seule destinée à être maintenue dans les prochaines versions de SQL Server.
vendredi 9 février 2007
Analysis Services 2000 Service Pack 4 - l'arme anti DSO distant !
Bonjour à tous !
Si le pilotage d'Analysis Services 2000 via le namespace DSO est extrêmement simple, comme nous l'avons vu précédemment, il n'en demeure pas moins surprenant que la connexion s'effectue correctement sans une chaîne de connexion bien formée.
En effet, seul le nom du serveur est fourni lors de la connexion avec les objets DSO. La chaîne de connexion est alors récupérée en base de registre, décryptée, et permet d'accéder au Repository d'Analysis Services.
En pratique, Analysis Services stocke deux chaînes de connexion encryptées dans la base de registre :
- une première chaîne pour les connexions locales :
Provider=Microsoft.Jet.OLEDB.4.0;Data Source=C:\Program Files\Microsoft Analysis Services\Bin\msmdrep.mdb
- une deuxième chaîne pour les connexions distantes :
Provider=Microsoft.Jet.OLEDB.4.0;Data Source=\\<NomDuServeur>\MsOLAPRepository$\msmdrep. mdb
Vous remarquerez ici que le Repository d'Analysis Services 2000 est stocké dans une base de données Access.
A partir du Service Pack 3, un bug est apparu concernant la connexion avec les objets DSO. Malheureusement, le HOTFIX réalisé à l'époque n'a pas été incorporé dans le Service Pack 4 d'Analysis Services 2000.
En effet, l'encryption de la chaîne de connexion distante est défaillante. Il en résulte que la chaîne de connexion décryptée par les objets DSO n'est pas valide.
Ainsi, lors d'une connexion distante via DSO, le message suivant peut-être obtenu :
Cannot connect to the repository. OLAP Server:Error: <NomDuServeur> [Microsoft][ODBC Driver Manager] Data source name too long
L'incompréhension vient souvent du fait que la même action effectuée avec une connexion locale ne pose aucun problème, brouillant un peu plus les pistes de correction.
Un bug incidieux donc, pour lequel vous trouverez un HOTFIX ici. La référence de la description du HOTFIX est KB907323.
Plus simplement, vous pouvez modifier la valeur de la clé contenant la chaîne de connexion distante en effectuant un click droit sur le nom de votre serveur dans Analysis Manager dans le menu "Edit Repository Connection String".
Bien entendu, il est totalement inutile de passer ce HOTFIX si vous ne rencontrez aucun problème ;-)
Si le pilotage d'Analysis Services 2000 via le namespace DSO est extrêmement simple, comme nous l'avons vu précédemment, il n'en demeure pas moins surprenant que la connexion s'effectue correctement sans une chaîne de connexion bien formée.
En effet, seul le nom du serveur est fourni lors de la connexion avec les objets DSO. La chaîne de connexion est alors récupérée en base de registre, décryptée, et permet d'accéder au Repository d'Analysis Services.
En pratique, Analysis Services stocke deux chaînes de connexion encryptées dans la base de registre :
- une première chaîne pour les connexions locales :
Provider=Microsoft.Jet.OLEDB.4.0;Data Source=C:\Program Files\Microsoft Analysis Services\Bin\msmdrep.mdb
- une deuxième chaîne pour les connexions distantes :
Provider=Microsoft.Jet.OLEDB.4.0;Data Source=\\<NomDuServeur>
Vous remarquerez ici que le Repository d'Analysis Services 2000 est stocké dans une base de données Access.
A partir du Service Pack 3, un bug est apparu concernant la connexion avec les objets DSO. Malheureusement, le HOTFIX réalisé à l'époque n'a pas été incorporé dans le Service Pack 4 d'Analysis Services 2000.
En effet, l'encryption de la chaîne de connexion distante est défaillante. Il en résulte que la chaîne de connexion décryptée par les objets DSO n'est pas valide.
Ainsi, lors d'une connexion distante via DSO, le message suivant peut-être obtenu :
Cannot connect to the repository. OLAP Server:
L'incompréhension vient souvent du fait que la même action effectuée avec une connexion locale ne pose aucun problème, brouillant un peu plus les pistes de correction.
Un bug incidieux donc, pour lequel vous trouverez un HOTFIX ici. La référence de la description du HOTFIX est KB907323.
Plus simplement, vous pouvez modifier la valeur de la clé contenant la chaîne de connexion distante en effectuant un click droit sur le nom de votre serveur dans Analysis Manager dans le menu "Edit Repository Connection String".
Bien entendu, il est totalement inutile de passer ce HOTFIX si vous ne rencontrez aucun problème ;-)
vendredi 12 janvier 2007
Comment choisir le nombre de grappes de disques...
Bonjour à tous !
Voici quelques conseils indémodables sur la séparation des fichiers de bases de données sur des grappes de disques - idéalement sur des contrôleurs - séparés...
Nous noterons tout d'abord que les différentes configurations adaptées aux bases de données isolent systématiquement les journaux de transactions sur un jeu de disques séparé, et cela pour deux raisons :
- Concernant la sécurité des données, la perte totale des disques de données peut être récupérée à l’aide des journaux de transactions, et inversement ;
- L’isolation des journaux de transactions assure de meilleures performances globales du système en limitant les files d’attentes sur les différents disques.
Ensuite, pour des raisons de performance générale de la base de données, il est primordial d'installer la base TempDB sur un jeu de disques isolé... En effet, toutes les bases de données du SGBD utilisent cette base pour créer des objets temporaires aux cours des différentes requêtes. Ceci est particulièrement important dans SQL Server 2005 !
Toujours pour des raisons d'optimisation des performances, il est souhaitable d'isoler les index non ordonnés (NONCLUSTERED) sur un jeu de disque séparé et ainsi accroitre les performances de recherche par ces index. En revanche, séparer les index CLUSTERED est totalement inutile, car cela reviendrait à déplacer la totalité des données...
Il est également recommandé de déplacer les données volumineuses - souvent baptisées BLOB pour Binary Large OBjects - sur un jeu de disques séparés afin de limiter le fractionnement des données... Pour cela, le partitionnement horizontal des données est nécessaire.
De plus en plus de bases de données présentent des volumes de données extrêmement important, ce qui peut grever grandement les performances. La solution du partitionnement vertical assure que les données soient séparées sur des espaces de données différents... Il est souvent intéressant d'isoler ces filegroups sur des jeux de disques séparés.
Enfin, il est important de rappeler que :
- Les disques systèmes ne sont pas des disques de données, et doivent être réservés à l'usage du système d'exploitation et des exécutables,
- Les disques servant de stockage de fichiers de backup lorsque cela s'applique doivent également être des disques dédiés pour éviter toute dégradation des performances de la base de données,
- Et que pour mettre en place ce type d'architecture, rien ne vaut le RAID... Alors bonne lecture !
Voici quelques conseils indémodables sur la séparation des fichiers de bases de données sur des grappes de disques - idéalement sur des contrôleurs - séparés...
Nous noterons tout d'abord que les différentes configurations adaptées aux bases de données isolent systématiquement les journaux de transactions sur un jeu de disques séparé, et cela pour deux raisons :
- Concernant la sécurité des données, la perte totale des disques de données peut être récupérée à l’aide des journaux de transactions, et inversement ;
- L’isolation des journaux de transactions assure de meilleures performances globales du système en limitant les files d’attentes sur les différents disques.
Ensuite, pour des raisons de performance générale de la base de données, il est primordial d'installer la base TempDB sur un jeu de disques isolé... En effet, toutes les bases de données du SGBD utilisent cette base pour créer des objets temporaires aux cours des différentes requêtes. Ceci est particulièrement important dans SQL Server 2005 !
Toujours pour des raisons d'optimisation des performances, il est souhaitable d'isoler les index non ordonnés (NONCLUSTERED) sur un jeu de disque séparé et ainsi accroitre les performances de recherche par ces index. En revanche, séparer les index CLUSTERED est totalement inutile, car cela reviendrait à déplacer la totalité des données...
Il est également recommandé de déplacer les données volumineuses - souvent baptisées BLOB pour Binary Large OBjects - sur un jeu de disques séparés afin de limiter le fractionnement des données... Pour cela, le partitionnement horizontal des données est nécessaire.
De plus en plus de bases de données présentent des volumes de données extrêmement important, ce qui peut grever grandement les performances. La solution du partitionnement vertical assure que les données soient séparées sur des espaces de données différents... Il est souvent intéressant d'isoler ces filegroups sur des jeux de disques séparés.
Enfin, il est important de rappeler que :
- Les disques systèmes ne sont pas des disques de données, et doivent être réservés à l'usage du système d'exploitation et des exécutables,
- Les disques servant de stockage de fichiers de backup lorsque cela s'applique doivent également être des disques dédiés pour éviter toute dégradation des performances de la base de données,
- Et que pour mettre en place ce type d'architecture, rien ne vaut le RAID... Alors bonne lecture !
Le RAID : les conclusions...
Il est donc temps pour moi d’en venir aux conclusions…
Si les différents niveaux de RAID sont si nombreux, la raison en est bien simple : chaque système possède des points forts et des points faibles à mettre en avant en fonction des besoins de chacun.
Cependant, il faut bien reconnaitre qu’un compromis est souvent nécessaire.
En la matière, le RAID 5 s'impose souvent comme le maître incontesté du rapport performance/coût... En revanche, les difficultés de sizing des bandes grevent les performances en écriture dans la majorité des systèmes de bases de données, entrainant de fait son rejet par les DBA puristes...
Qui eux, sans aucun doute feront le choix du RAID 10, certes plus coûteux, mais assurant des performances constantes quelques soient les modes d'accès. Un avantage indéniable, quand on peut aisément lui associer une meilleure vitesse de reconstruction des données, une dégradation des performances inférieure en cas de panne, une meilleure tolérance de panne... Et une installation plus simple à réaliser !
Enfin, il ne faut pas négliger les disques destinés au système d'exploitation, qui mérite sans aucun doute de bénéficier d'un bon RAID 1, peu coûteux, et répondant idéalement aux prérequis de disponibilité du système.
Alors, à vos marques... Configurez !
Si les différents niveaux de RAID sont si nombreux, la raison en est bien simple : chaque système possède des points forts et des points faibles à mettre en avant en fonction des besoins de chacun.
Cependant, il faut bien reconnaitre qu’un compromis est souvent nécessaire.
En la matière, le RAID 5 s'impose souvent comme le maître incontesté du rapport performance/coût... En revanche, les difficultés de sizing des bandes grevent les performances en écriture dans la majorité des systèmes de bases de données, entrainant de fait son rejet par les DBA puristes...
Qui eux, sans aucun doute feront le choix du RAID 10, certes plus coûteux, mais assurant des performances constantes quelques soient les modes d'accès. Un avantage indéniable, quand on peut aisément lui associer une meilleure vitesse de reconstruction des données, une dégradation des performances inférieure en cas de panne, une meilleure tolérance de panne... Et une installation plus simple à réaliser !
Enfin, il ne faut pas négliger les disques destinés au système d'exploitation, qui mérite sans aucun doute de bénéficier d'un bon RAID 1, peu coûteux, et répondant idéalement aux prérequis de disponibilité du système.
Alors, à vos marques... Configurez !
RAID 103, 105 et les autres...
Actuellement, bon nombre de sociétés sont à la recherche d’une solution permettant d’améliorer les performances en écriture du RAID 10, son point faible. Ces solutions intègrent également des niveaux de sécurité extrêmement importants.
Des solutions complexes du type RAID 103 et RAID 105 sont actuellement à l’étude. Si leur mise en œuvre parait extrêmement complexe, les performances obtenues n’en demeurent pas moins très prometteuses.
Aucune carte contrôleur disponible sur le marché ne permet actuellement de gérer de telles configurations physiquement qui sont uniquement du domaine de la recherche pour l’instant… A suivre ;-)
Des solutions complexes du type RAID 103 et RAID 105 sont actuellement à l’étude. Si leur mise en œuvre parait extrêmement complexe, les performances obtenues n’en demeurent pas moins très prometteuses.
Aucune carte contrôleur disponible sur le marché ne permet actuellement de gérer de telles configurations physiquement qui sont uniquement du domaine de la recherche pour l’instant… A suivre ;-)
RAID 15 et 51...
L’intérêt majeur de mutualiser ces deux types de RAID réside dans la robustesse de ce modèle en termes de sécurité des données ; la tolérance de panne ainsi obtenue s’avère impressionnante. On peut ainsi perdre la plupart des disques sur un RAID 15 (7/9 disques par exemple). C’est le meilleur niveau de RAID en termes de tolérance de panne et en termes de disponibilité. Mais c’est un RAID très coûteux, en raison du coût important des cartes contrôleurs qui lui sont adaptées d’une part, et en raison d’une capacité de stockage très fortement réduite – présentant des pertes de plus de 70% de l’espace disque total dans certaines de configurations – d’autre part. Les performances de ces types de RAID ne sont jamais exceptionnelles, mais ne s’avèrent jamais catastrophiques pour autant. Il s’agit d’un excellent compromis pour des cas où la sécurité est primordiale.
Toutefois, la plupart du temps, les RAID 15 et 51 peuvent avantageusement être remplacés par du RAID 10. En effet, un système nécessitant un tel niveau de sécurité pose toujours la question de la fiabilité de ses équipements.
Toutefois, la plupart du temps, les RAID 15 et 51 peuvent avantageusement être remplacés par du RAID 10. En effet, un système nécessitant un tel niveau de sécurité pose toujours la question de la fiabilité de ses équipements.
RAID 05 et 50...
Comme pour les RAID 01 et 10, et les RAID 03 et 30, on privilégiera ici le RAID 50, car il s’agit du niveau le plus fiable en termes de dégradation des performances en cas de panne et de temps de reconstruction des disques de données. Le RAID 50 s’avère beaucoup plus cher que le RAID 10, mais présente des performances très comparables à celui-ci (excellentes performances en lecture et en écriture). Son intérêt majeur réside dans sa capacité de disque qui n’est pas réduite de 50%. On peut par exemple, avec 6 disques, conserver 80% de l’espace de ceux-ci !
Comme pour tous les RAID composites, un contrôleur performant est nécessaire, et le RAID 50 est souvent utilisé avec du duplexing afin de gérer la problématique des pannes de contrôleurs. Les performances en lecture sont excellente, permettant de considérer le RAID 50 comme l’un des meilleurs RAID composites en écriture séquentielle, malgré une légère faiblesse en écriture aléatoire en comparaison du RAID 10 par exemple à cause de son besoin de tout relire pour, comme toujours, des problèmes de calcul de parité.
Malgré sa légère déperdition de performances en lecture due à la présence des informations de parité, le RAID 50 s’impose également comme un excellent niveau concernant les accès en lecture, ne voyant pas ses performances diminuées par le choix technique des cartes contrôleurs RAID 10 de privilégier les accès concurrentiels.
Comme pour tous les RAID composites, un contrôleur performant est nécessaire, et le RAID 50 est souvent utilisé avec du duplexing afin de gérer la problématique des pannes de contrôleurs. Les performances en lecture sont excellente, permettant de considérer le RAID 50 comme l’un des meilleurs RAID composites en écriture séquentielle, malgré une légère faiblesse en écriture aléatoire en comparaison du RAID 10 par exemple à cause de son besoin de tout relire pour, comme toujours, des problèmes de calcul de parité.
Malgré sa légère déperdition de performances en lecture due à la présence des informations de parité, le RAID 50 s’impose également comme un excellent niveau concernant les accès en lecture, ne voyant pas ses performances diminuées par le choix technique des cartes contrôleurs RAID 10 de privilégier les accès concurrentiels.
RAID 03 et 30...
Il n’y a que très peu de différences entre ces deux types de RAID, sauf en ce qui concerne la dégradation des performances suite à une éventuelle panne. Le RAID 30 a en effet des vitesses de reconstruction inférieures au RAID 03, mais toujours supérieures à du RAID 10. Il est cependant très utilisé pour de très larges bases de données stockées sur de très larges serveurs de fichiers. C’est un RAID cher, que je n’aime pas du tout parce que ses performances sont mauvaises en termes d’écriture, notamment aléatoire, en particulier dues au goulot d’étranglement dû au RAID 3 qui présente un disque de parité dédié. Ce RAID peut s’avérer intéressant en lecture, surtout aléatoire, si la taille de la bande est suffisamment large. En revanche, ce RAID est une véritable catastrophe en écriture…
Nous noterons l’appellation commerciale usurpée RAID 53 qui est en réalité un RAID 03. Je ne m’attarde pas ici sur les piètres performances de ce niveau réservé au stockage de volumes importants de fichiers présentant un faible taux de rafraichissement.
Nous noterons l’appellation commerciale usurpée RAID 53 qui est en réalité un RAID 03. Je ne m’attarde pas ici sur les piètres performances de ce niveau réservé au stockage de volumes importants de fichiers présentant un faible taux de rafraichissement.
RAID 01 – Mirrored stripes – et 10 – striped mirrors
La grande différence entre le RAID 10 et le RAID 01 est évidemment l’ordre dans lequel les RAID sont implémentés.
Dans les deux cas, le coût en termes de disques est identique, à savoir relativement élevé compte tenu de la capacité qui est divisée par le nombre de miroirs ; dans tous les cas, on perd donc au moins 50% de la capacité disque achetée ! En revanche, le coût des cartes contrôleurs peut s’avérer très différent : la majorité des cartes grand public permettent d’implémenter uniquement le RAID 01.
En ce qui concerne les résultats obtenus, ils sont évidemment très différents entre les deux types de RAID. On s’aperçoit en fait rapidement que le RAID 10 est bien supérieur au RAID 01 dans un certain nombre de domaines : en effet, le RAID 10 a tout d’abord une bien meilleure tolérance de panne égale au (([nombre de disques en RAID 1] - 1) * [nombre de jeux de disques en RAID 0]) en RAID 10 alors qu’elle n’est que du ([nombre de jeux de disques en RAID 1] - 1) pour le RAID 01. Ensuite, le RAID 01 n’apporte pas de meilleures performances que le RAID 10, alors qu’il s’avère plus lent au cours de la reconstruction des données après une panne. De même, la perte d’un disque peut grever de façon beaucoup plus perceptible un système reposant sur du RAID 01.
Enfin, et même si toutes les cartes contrôleurs ne le supportent pas, le RAID 10 présente d’excellentes performances en lecture (vitesse divisée par n) et en écriture (vitesse divisée par le nombre de jeu de disques en RAID 0).
Ainsi, le RAID 10 est recommandable pour tout type de bases de données… Même si son coût plus élevé qu’un RAID 5, par exemple, le relègue souvent au second plan.
Nous noterons les formules théoriques suivantes pour le RAID 10, en fonction du nombre de disques n et en supposant que le RAID 1 n’est employé que par paires de disques :
- Nombre de disques au minimum : 4
- Espace disque : (n/2) * [Espace disque du plus petit des disques]
- Temps d'écriture : (2/n) * [Temps d'accès en écriture du plus lent des disques]
- Temps de lecture : n * [Temps d'accès en lecture du plus lent des disques]
- Tolérance de panne : n/2
Nous en conclurons de façon évidente une certaine supériorité de ce modèle sur le RAID 5 pour toutes les écritures aléatoires. Nous noterons également la propension des cartes contrôleurs gérant ce niveau de RAID à privilégier des accès concurrentiels aux données en lecture plutôt qu’une parallélisation d’une lecture, grevant de fait les performances théoriques présentées ci-dessus.
Dans les deux cas, le coût en termes de disques est identique, à savoir relativement élevé compte tenu de la capacité qui est divisée par le nombre de miroirs ; dans tous les cas, on perd donc au moins 50% de la capacité disque achetée ! En revanche, le coût des cartes contrôleurs peut s’avérer très différent : la majorité des cartes grand public permettent d’implémenter uniquement le RAID 01.
En ce qui concerne les résultats obtenus, ils sont évidemment très différents entre les deux types de RAID. On s’aperçoit en fait rapidement que le RAID 10 est bien supérieur au RAID 01 dans un certain nombre de domaines : en effet, le RAID 10 a tout d’abord une bien meilleure tolérance de panne égale au (([nombre de disques en RAID 1] - 1) * [nombre de jeux de disques en RAID 0]) en RAID 10 alors qu’elle n’est que du ([nombre de jeux de disques en RAID 1] - 1) pour le RAID 01. Ensuite, le RAID 01 n’apporte pas de meilleures performances que le RAID 10, alors qu’il s’avère plus lent au cours de la reconstruction des données après une panne. De même, la perte d’un disque peut grever de façon beaucoup plus perceptible un système reposant sur du RAID 01.
Enfin, et même si toutes les cartes contrôleurs ne le supportent pas, le RAID 10 présente d’excellentes performances en lecture (vitesse divisée par n) et en écriture (vitesse divisée par le nombre de jeu de disques en RAID 0).
Ainsi, le RAID 10 est recommandable pour tout type de bases de données… Même si son coût plus élevé qu’un RAID 5, par exemple, le relègue souvent au second plan.
Nous noterons les formules théoriques suivantes pour le RAID 10, en fonction du nombre de disques n et en supposant que le RAID 1 n’est employé que par paires de disques :
- Nombre de disques au minimum : 4
- Espace disque : (n/2) * [Espace disque du plus petit des disques]
- Temps d'écriture : (2/n) * [Temps d'accès en écriture du plus lent des disques]
- Temps de lecture : n * [Temps d'accès en lecture du plus lent des disques]
- Tolérance de panne : n/2
Nous en conclurons de façon évidente une certaine supériorité de ce modèle sur le RAID 5 pour toutes les écritures aléatoires. Nous noterons également la propension des cartes contrôleurs gérant ce niveau de RAID à privilégier des accès concurrentiels aux données en lecture plutôt qu’une parallélisation d’une lecture, grevant de fait les performances théoriques présentées ci-dessus.
Le RAID composite...
Il est impossible depuis quelques années de s’attaquer à la description des niveaux de RAID si l’on omet l’existence de la possibilité de les composer. Ainsi, il est envisageable de cumuler les avantages des différents niveaux de RAID.
Le principe est donc d’appliquer un niveau de RAID sur un autre niveau de RAID ; par exemple, si on fait du RAID xy (ou x+y, même si cette notation commerciale s’avère souvent mensongère), c’est qu’on applique du raid y sur du raid x.
Et voici maintenant un série de posts sur les niveaux les plus courants de RAID composite !
Le principe est donc d’appliquer un niveau de RAID sur un autre niveau de RAID ; par exemple, si on fait du RAID xy (ou x+y, même si cette notation commerciale s’avère souvent mensongère), c’est qu’on applique du raid y sur du raid x.
Et voici maintenant un série de posts sur les niveaux les plus courants de RAID composite !
RAID 7 - Asynchronous, cached striping with dedicated parity...
Il s'agit d'un niveau de RAID propriétaire développé par Storage Computer Corporation. Si le RAID 7 permet de faire preuve d'un niveau de performances exceptionnel, il n'en demeure pas moins rare... et très cher !
C’est un RAID qui utilise le cache du contrôleur à outrance, ce qui fait de lui le plus performant des RAID simples : il obtient ainsi les meilleures performances en termes de lectures aléatoires (cache power !!), et d’écritures aléatoires (il est en striping avec parité dédiée en cache). Les performances sont remarquables mais excessivement chères. Pour la plupart des utilisateurs, le coût prohibitif de ce niveau de RAID le rende inaccessible.
Je ne m’étendrai donc pas non plus sur ce niveau si particulier.
C’est un RAID qui utilise le cache du contrôleur à outrance, ce qui fait de lui le plus performant des RAID simples : il obtient ainsi les meilleures performances en termes de lectures aléatoires (cache power !!), et d’écritures aléatoires (il est en striping avec parité dédiée en cache). Les performances sont remarquables mais excessivement chères. Pour la plupart des utilisateurs, le coût prohibitif de ce niveau de RAID le rende inaccessible.
Je ne m’étendrai donc pas non plus sur ce niveau si particulier.
RAID 6 - Block-level striping with dual distributed parity...
C’est un RAID 5 qui est un peu amélioré en termes de sécurité des données. Il autorise en effet la perte de 2 disques au lieu d’un. Toutefois, dans la majeure partie des cas, il demeure trop cher par rapport au RAID 5, pour des performances légèrement moins bonnes (les calculs se font en double parité, ce qui engendre une grande complexité). Il devrait en théorie être utilisé dans des systèmes sensibles, mais il faut bien avouer qu’il est très rare que deux disques tombent en panne en même temps, d’où un aspect « gadget » du RAID 6. En effet, les cas de panne de plus d’un disque simultanément résultent généralement d’une panne majeure qui risque d’endommager plus de 2 disques. Si une forte tolérance de panne est nécessaire, on privilégiera de fait l’utilisation du mirroring beaucoup plus sécurisant, rendant le RAID 6 assez inutile.
Enfin, outre le coût important des cartes contrôleurs gérant ce niveau de RAID, sa plus grande perte d’espace disque en font l’un des plus chers des niveaux définis par Berkeley.
Nous noterons les formules théoriques suivantes, en fonction du nombre de disques n :
- Nombre de disques au minimum : 4
- Espace disque : (n-2) * [Espace disque du plus petit des disques]
- Temps d'écriture : (1/(n-2)) * [Temps d'accès en écriture du plus lent des disques]
- Temps de lecture : (1/(n-2)) * [Temps d'accès en lecture du plus lent des disques]
- Tolérance de panne : 2
Enfin, outre le coût important des cartes contrôleurs gérant ce niveau de RAID, sa plus grande perte d’espace disque en font l’un des plus chers des niveaux définis par Berkeley.
Nous noterons les formules théoriques suivantes, en fonction du nombre de disques n :
- Nombre de disques au minimum : 4
- Espace disque : (n-2) * [Espace disque du plus petit des disques]
- Temps d'écriture : (1/(n-2)) * [Temps d'accès en écriture du plus lent des disques]
- Temps de lecture : (1/(n-2)) * [Temps d'accès en lecture du plus lent des disques]
- Tolérance de panne : 2
RAID 5 - Block-level striping with distributed parity...
Le RAID 5 fonctionne comme le RAID 4, selon un “block-level” qui permet de définir la taille des bandes d’enregistrement. La grande différence avec le RAID 4, c’est que la parité est distribuée : le RAID 5 écrit ainsi ses bits de parité sur chaque disque à tour de rôle. Ce concept permet donc de supprimer le goulot d’étranglement sur le disque de parité.
Beaucoup moins cher, parce que très utilisé et très commun sur le marché, le RAID 5 présente de nombreux avantages. C’est d'ailleurs selon moi le meilleur compromis coût/performance pour un grand nombre de raisons.
Sa tolérance de panne d’un disque lui assure un niveau de sécurité satisfaisant.
Au niveau théorique, les capacités du RAID 5 en termes de stockage sont de n-1 disques, et ses vitesses d’écriture et de lecture sont divisées par n-1, ce qui lui confère des performances honorables.
Il se trouve donc supérieur au RAID 1 pour l’écriture, même s’il lui est légèrement inférieur en lecture ; à priori, il est donc plus performant pour des disques où le volume d’écritures est important. Ceci n’est totalement vrai que si l’on ne fait que de l’écriture séquentielle. En effet, au cours d’une écriture aléatoire, certains blocs sont modifiés, et nécessitent donc la modification de la parité de la bande. Il faut donc lire l’ensemble de la bande pour reconstituer la parité ; chaque écriture aléatoire donne donc lieu à deux entrées/sorties. Et avec 2 I/O, le système se voit très ralenti ! C’est le gros point noir…
Cependant, dans la pratique, on s’aperçoit que le RAID 5 reste très employé, en particulier dans les bases de données ; alors même que celles-ci ont énormément d’écritures aléatoires !
Enfin, en termes de coûts, le RAID 5 se fait la part belle grâce à sa bonne capacité de stockage et un coût relativement faible des cartes contrôleurs adaptées.
Au final, le RAID 5 me paraît donc plutôt adapté, voire idéal, pour les journaux de transactions, compte tenu de l’utilisation quasi exclusive d’écritures séquentielles, pour lesquelles la problématique du calcul de parité ne se présente pas. Il faut cependant s’assurer de la taille des blocs de données afin d’éviter d’écrire une transaction sur moins d’une bande revenant alors à des écritures aléatoires. Les spécifications actuelles qui préconisent d’appliquer du RAID 10 apparaissent donc comme sous performantes, même si les difficultés de mise en œuvre d’un RAID 5 bien dimensionné expliquent sans aucun doute ce choix. En revanche, l’utilisation de ce niveau de RAID s’avère beaucoup plus discutable en ce qui concerne les bases de données auxquelles je privilégierai un RAID 10.
Nous noterons les formules théoriques suivantes, en fonction du nombre de disques n :
- Nombre de disques au minimum : 3
- Espace disque : (n-1) * [Espace disque du plus petit des disques]
- Temps d'écriture : (1/(n-1)) * [Temps d'accès en écriture du plus lent des disques]
- Temps de lecture : (1/(n-1)) * [Temps d'accès en lecture du plus lent des disques]
- Tolérance de panne : 1
Auxquelles nous ajouterons le temps d’écriture aléatoire théorique, le temps de lecture restant identique quelque soit le mode :
- Temps d’écriture : (2/(n-1)) * [Temps d'accès en écriture du plus lent des disques]
Beaucoup moins cher, parce que très utilisé et très commun sur le marché, le RAID 5 présente de nombreux avantages. C’est d'ailleurs selon moi le meilleur compromis coût/performance pour un grand nombre de raisons.
Sa tolérance de panne d’un disque lui assure un niveau de sécurité satisfaisant.
Au niveau théorique, les capacités du RAID 5 en termes de stockage sont de n-1 disques, et ses vitesses d’écriture et de lecture sont divisées par n-1, ce qui lui confère des performances honorables.
Il se trouve donc supérieur au RAID 1 pour l’écriture, même s’il lui est légèrement inférieur en lecture ; à priori, il est donc plus performant pour des disques où le volume d’écritures est important. Ceci n’est totalement vrai que si l’on ne fait que de l’écriture séquentielle. En effet, au cours d’une écriture aléatoire, certains blocs sont modifiés, et nécessitent donc la modification de la parité de la bande. Il faut donc lire l’ensemble de la bande pour reconstituer la parité ; chaque écriture aléatoire donne donc lieu à deux entrées/sorties. Et avec 2 I/O, le système se voit très ralenti ! C’est le gros point noir…
Cependant, dans la pratique, on s’aperçoit que le RAID 5 reste très employé, en particulier dans les bases de données ; alors même que celles-ci ont énormément d’écritures aléatoires !
Enfin, en termes de coûts, le RAID 5 se fait la part belle grâce à sa bonne capacité de stockage et un coût relativement faible des cartes contrôleurs adaptées.
Au final, le RAID 5 me paraît donc plutôt adapté, voire idéal, pour les journaux de transactions, compte tenu de l’utilisation quasi exclusive d’écritures séquentielles, pour lesquelles la problématique du calcul de parité ne se présente pas. Il faut cependant s’assurer de la taille des blocs de données afin d’éviter d’écrire une transaction sur moins d’une bande revenant alors à des écritures aléatoires. Les spécifications actuelles qui préconisent d’appliquer du RAID 10 apparaissent donc comme sous performantes, même si les difficultés de mise en œuvre d’un RAID 5 bien dimensionné expliquent sans aucun doute ce choix. En revanche, l’utilisation de ce niveau de RAID s’avère beaucoup plus discutable en ce qui concerne les bases de données auxquelles je privilégierai un RAID 10.
Nous noterons les formules théoriques suivantes, en fonction du nombre de disques n :
- Nombre de disques au minimum : 3
- Espace disque : (n-1) * [Espace disque du plus petit des disques]
- Temps d'écriture : (1/(n-1)) * [Temps d'accès en écriture du plus lent des disques]
- Temps de lecture : (1/(n-1)) * [Temps d'accès en lecture du plus lent des disques]
- Tolérance de panne : 1
Auxquelles nous ajouterons le temps d’écriture aléatoire théorique, le temps de lecture restant identique quelque soit le mode :
- Temps d’écriture : (2/(n-1)) * [Temps d'accès en écriture du plus lent des disques]
RAID 4 - Block-level striping with dedicated parity...
Le RAID 4, comme nous l’avons dit, s’apparente au RAID 3 à un (gros !) détail près : la largeur de bande est divisée en blocs et non pas en octets. On peut ainsi définir la largeur des bandes, ce qui est particulièrement utile pour les écritures aléatoires, parce qu’il est possible de calculer la taille des blocs de l’enregistrement afin d’optimiser l’espace disque.
Souvent confondu avec le RAID 3, moins utilisé, le RAID 4 est un compromis sans cible sur le marché. Il ne doit selon moi jamais être utilisé parce qu’il n’a pas vraiment d’intérêt en termes de gains de performance. On retrouve le goulot d’étranglement du RAID 3, il coûte encore plus cher et peu de cartes contrôleurs supportent le RAID 4.
Nous noterons les formules théoriques suivantes, en fonction du nombre de disques n :
- Nombre de disques au minimum : 3
- Espace disque : (n-1) * [Espace disque du plus petit des disques]
- Temps d'écriture : (1/(n-1)) * [Temps d'accès en écriture du plus lent des disques]
- Temps de lecture : (1/(n-1)) * [Temps d'accès en lecture du plus lent des disques]
- Tolérance de panne : 1
Souvent confondu avec le RAID 3, moins utilisé, le RAID 4 est un compromis sans cible sur le marché. Il ne doit selon moi jamais être utilisé parce qu’il n’a pas vraiment d’intérêt en termes de gains de performance. On retrouve le goulot d’étranglement du RAID 3, il coûte encore plus cher et peu de cartes contrôleurs supportent le RAID 4.
Nous noterons les formules théoriques suivantes, en fonction du nombre de disques n :
- Nombre de disques au minimum : 3
- Espace disque : (n-1) * [Espace disque du plus petit des disques]
- Temps d'écriture : (1/(n-1)) * [Temps d'accès en écriture du plus lent des disques]
- Temps de lecture : (1/(n-1)) * [Temps d'accès en lecture du plus lent des disques]
- Tolérance de panne : 1
Raid 3 - Byte-level striping with dedicated parity...
En RAID 3, les bandes ont une largeur fixe d’un octet, et ne sont donc pas modulables. Le terme « Dedicated parity » du titre signifie que les informations de parité sont écrites sur un disque dédié. Les informations de parité sont le résultat d’un calcul à base de « ou exclusifs » permettant de reconstituer les données d’un disque à l’aide des données présente dans les autres disques.
Le RAID 3 est un niveau de RAID qui est, à tort, souvent confondu avec le RAID 4. La seule différence réside en effet dans la taille des bandes pour le striping : si le RAID 3 dispose de bandes de largeur fixe, le RAID 4 permet de configurer la largeur de celles-ci.
Le RAID 3 offre une tolérance à la panne assez bonne, étant donné que l’on peut perdre un disque.
La vitesse d’écriture théorique, de 1/(n-1), reste toutefois largement fantaisiste : en effet, pour atteindre ces résultats, il faudrait que le disque de parité soit (n-1) fois plus rapide que les autres disques ; comme il est dédié, à chaque fois que l’on écrit sur un disque, on est supposé écrire sur le disque de parité, ce qui ralentit considérablement les choses, en particulier en écriture aléatoire. Il existe donc un goulot d’étranglement sur le disque de parité, qui est par ailleurs beaucoup plus sensible aux pannes en raison de sa beaucoup plus forte utilisation.
Nous noterons les formules théoriques suivantes, en fonction du nombre de disques n :
- Nombre de disques au minimum : 3
- Espace disque : (n-1) * [Espace disque du plus petit des disques]
- Temps d'écriture : (1/(n-1)) * [Temps d'accès en écriture du plus lent des disques]
- Temps de lecture : (1/(n-1)) * [Temps d'accès en lecture du plus lent des disques]
- Tolérance de panne : 1
Le RAID 3 est un niveau de RAID qui est, à tort, souvent confondu avec le RAID 4. La seule différence réside en effet dans la taille des bandes pour le striping : si le RAID 3 dispose de bandes de largeur fixe, le RAID 4 permet de configurer la largeur de celles-ci.
Le RAID 3 offre une tolérance à la panne assez bonne, étant donné que l’on peut perdre un disque.
La vitesse d’écriture théorique, de 1/(n-1), reste toutefois largement fantaisiste : en effet, pour atteindre ces résultats, il faudrait que le disque de parité soit (n-1) fois plus rapide que les autres disques ; comme il est dédié, à chaque fois que l’on écrit sur un disque, on est supposé écrire sur le disque de parité, ce qui ralentit considérablement les choses, en particulier en écriture aléatoire. Il existe donc un goulot d’étranglement sur le disque de parité, qui est par ailleurs beaucoup plus sensible aux pannes en raison de sa beaucoup plus forte utilisation.
Nous noterons les formules théoriques suivantes, en fonction du nombre de disques n :
- Nombre de disques au minimum : 3
- Espace disque : (n-1) * [Espace disque du plus petit des disques]
- Temps d'écriture : (1/(n-1)) * [Temps d'accès en écriture du plus lent des disques]
- Temps de lecture : (1/(n-1)) * [Temps d'accès en lecture du plus lent des disques]
- Tolérance de panne : 1
RAID 2 - Bit-level striping with Hamming code...
C’est le seul striping qui n’utilise pas un aspect de parité. Il s’agit ici d’un striping au niveau des bits, les bandes ne pouvant pas être étendues, puisqu’elles n’ont qu’un bit. Il est intéressant de noter qu’elles sont validées par un code de contrôle d’erreur de Hamming (ECC ou Error Correcting Code).
Le gros avantage du RAID 2 était sa disponibilité parce qu’il effectuait des corrections « on the fly », à chaud… mais cela ne sert aujourd’hui plus à grand-chose étant donné que la quasi-totalité des disques durs actuels utilisent le code ECC.
Ainsi, le RAID 2, qui est par ailleurs très mauvais en écriture et lecture aléatoires, n’est absolument plus utilisé.
Je ne m'étendrai donc pas plus sur ce niveau obsolète.
Le gros avantage du RAID 2 était sa disponibilité parce qu’il effectuait des corrections « on the fly », à chaud… mais cela ne sert aujourd’hui plus à grand-chose étant donné que la quasi-totalité des disques durs actuels utilisent le code ECC.
Ainsi, le RAID 2, qui est par ailleurs très mauvais en écriture et lecture aléatoires, n’est absolument plus utilisé.
Je ne m'étendrai donc pas plus sur ce niveau obsolète.
RAID 1 - Mirroring, shadowing, duplexing...
Le RAID 1 peut être appelé de différentes façons : mirroring, shadowing ou encore duplexing... Il s'agit tout simplement de copier l'intégralité des données sur chacun des disques. Ainsi, le RAID 1 est un système possédant une grande tolérance de panne. Par exemple, si l'on dispose de 3 disques en RAID 1, les données restent disponibles malgré la perte de 2 disques. Dans le cas du duplexing, il s’agit également de redonder les contrôleurs afin de gérer une tolérance de panne à ce niveau également.
Lors de la phase de lecture des données, le RAID 1 permet de paralléliser la lecture et ainsi d'obtenir, en théorie, des performances 3 fois plus rapides avec 3 disques ! En pratique, les gains en performance en lecture sont très proches des gains observés en RAID 0 lorsque la lecture est parallélisée. Toujours dans la pratique, le RAID 1 permet également d’effectuer deux lectures simultanées pour deux espaces disques différents ce qui offre la possibilité d’améliorer les files d’attentes disques. Le RAID 1 est particulièrement efficace pour la lecture aléatoire, où il est bien meilleur qu’un disque simple, même s’il reste inférieur dans ce domaine à d’autres types de RAID. Le RAID 1 ne brille pas en écriture mais se distingue en lecture : en effet, lorsqu’on écrit, on écrit la même chose sur tous les disques, donc le temps d’écriture est le même que pour un disque simple. En revanche, en lecture, on lit n fois plus vite, en parallélisant la lecture et les accès.
Toutefois, beaucoup de contrôleurs de disques ne savent pas paralléliser les lectures, ce qui engendre de faibles gains de performance en lecture in fine. Au final, l’on peut penser que le RAID 1 est extrêmement sensible au type de contrôleur fourni. Si celui-ci est de bonne qualité, comme cela est généralement le cas dans le milieu professionnel, il est possible de paralléliser les lectures, ce qui rend le RAID 1 intéressant pour un faible niveau d’écriture et un gros volume de lecture, qu’elle soit séquentielle ou aléatoire.
Enfin, il est intéressant de noter qu’un RAID 1, en écriture aléatoire, s’avère parfois plus efficace que beaucoup de RAID avec calcul de parité parce qu’il n’est pas obligé de relire les données sur les différents disques.
Il est à noter que le RAID 1, tout comme le RAID 0 aligne ses performances sur les disques les plus faibles.
L'inconvénient majeur du RAID 1 est sans aucun doute son coût élevé compte tenu de la perte importante de capacité totale des disques : la capacité finale est en effet logiquement d’un seul disque quel que soit le nombre de disques mis en place. Par exemple, monter 5 disques en RAID 1 n’offre qu’une capacité d’un seul disque !
Le RAID 1 est très utilisé en milieu professionnel pour tous les systèmes nécessitant un fort niveau de disponibilité. De plus, le RAID 1 offre une vitesse de reconstruction des données extrêmement performante puisqu’il s’agit d’une simple copie de disque. Cela assure également de minimiser les impacts sur les performances au cours de cette reconstruction. La majorité des serveurs disposent donc de ce niveau de RAID pour les disques systèmes.
Nous noterons les formules théoriques suivantes, en fonction du nombre de disques n :
- Nombre de disques au minimum : 2
- Espace disque : [Espace disque du plus petit des disques]
- Temps d'écriture : [Temps d'accès en écriture du plus lent des disques]
- Temps de lecture : (1/n) * [Temps d'accès en lecture du plus lent des disques]
- Tolérance de panne : n-1
Lors de la phase de lecture des données, le RAID 1 permet de paralléliser la lecture et ainsi d'obtenir, en théorie, des performances 3 fois plus rapides avec 3 disques ! En pratique, les gains en performance en lecture sont très proches des gains observés en RAID 0 lorsque la lecture est parallélisée. Toujours dans la pratique, le RAID 1 permet également d’effectuer deux lectures simultanées pour deux espaces disques différents ce qui offre la possibilité d’améliorer les files d’attentes disques. Le RAID 1 est particulièrement efficace pour la lecture aléatoire, où il est bien meilleur qu’un disque simple, même s’il reste inférieur dans ce domaine à d’autres types de RAID. Le RAID 1 ne brille pas en écriture mais se distingue en lecture : en effet, lorsqu’on écrit, on écrit la même chose sur tous les disques, donc le temps d’écriture est le même que pour un disque simple. En revanche, en lecture, on lit n fois plus vite, en parallélisant la lecture et les accès.
Toutefois, beaucoup de contrôleurs de disques ne savent pas paralléliser les lectures, ce qui engendre de faibles gains de performance en lecture in fine. Au final, l’on peut penser que le RAID 1 est extrêmement sensible au type de contrôleur fourni. Si celui-ci est de bonne qualité, comme cela est généralement le cas dans le milieu professionnel, il est possible de paralléliser les lectures, ce qui rend le RAID 1 intéressant pour un faible niveau d’écriture et un gros volume de lecture, qu’elle soit séquentielle ou aléatoire.
Enfin, il est intéressant de noter qu’un RAID 1, en écriture aléatoire, s’avère parfois plus efficace que beaucoup de RAID avec calcul de parité parce qu’il n’est pas obligé de relire les données sur les différents disques.
Il est à noter que le RAID 1, tout comme le RAID 0 aligne ses performances sur les disques les plus faibles.
L'inconvénient majeur du RAID 1 est sans aucun doute son coût élevé compte tenu de la perte importante de capacité totale des disques : la capacité finale est en effet logiquement d’un seul disque quel que soit le nombre de disques mis en place. Par exemple, monter 5 disques en RAID 1 n’offre qu’une capacité d’un seul disque !
Le RAID 1 est très utilisé en milieu professionnel pour tous les systèmes nécessitant un fort niveau de disponibilité. De plus, le RAID 1 offre une vitesse de reconstruction des données extrêmement performante puisqu’il s’agit d’une simple copie de disque. Cela assure également de minimiser les impacts sur les performances au cours de cette reconstruction. La majorité des serveurs disposent donc de ce niveau de RAID pour les disques systèmes.
Nous noterons les formules théoriques suivantes, en fonction du nombre de disques n :
- Nombre de disques au minimum : 2
- Espace disque : [Espace disque du plus petit des disques]
- Temps d'écriture : [Temps d'accès en écriture du plus lent des disques]
- Temps de lecture : (1/n) * [Temps d'accès en lecture du plus lent des disques]
- Tolérance de panne : n-1
RAID 0 - Striping (without parity)...
Il s'agit d'une version "améliorée" du JBOD permettant d'accélérer les performances en parallélisant les écritures sur l'ensemble de disque. En français, on parle d'"entrelacement" ou d'"agrégat par bandes". Le RAID 0 devrait être qualifié uniquement de AID, car il ne dispose pas de redondance.
Ainsi, si l'on dispose de 2 disques et que l'on souhaite écrire 200 Go, le RAID 0 permettra d'écrire 100 Go sur chacun des disques. La théorie permet donc d'obtenir des performances 2 fois supérieures. Dans la pratique, avec l'utilisation de 2 disques, un gain de performance de 40% est excellent, à mettre en rapport avec les 50% attendus théoriquement.
Le RAID 0 est performant partout, en lecture et en écriture, qu’elles soient aléatoires mais surtout séquentielles. Pour tout ce qui concerne des lectures ou écritures aléatoires, si le contrôleur de disque supporte des lectures indépendantes sur les différents disques, on gagne à utiliser des bandes plus larges.
Il est à noter que les performances de l'ensemble des disques durs - taille, temps d'accès, ... - s'alignent sur le disque le plus faible. Ainsi, le disque le plus petit fixera la taille, le disque le plus lent fixera le temps d'accès, ... Cette restriction est applicable pour tous les autres niveaux de RAID à l'exception du JBOD.
Malgré ses excellentes performances, le RAID 0 n'est pas utilisé pour le stockage des données en milieu professionnel car il ne dispose pas de tolérance de panne.
Nous noterons les formules théoriques suivantes, en fonction du nombre de disques n :
- Nombre de disques au minimum : 2
- Espace disque : n * [Espace disque du plus petit des disques]
- Temps d'écriture : (1/n) * [Temps d'accès en écriture du plus lent des disques]
- Temps de lecture : (1/n) * [Temps d'accès en lecture du plus lent des disques]
- Tolérance de panne : 0
Ainsi, si l'on dispose de 2 disques et que l'on souhaite écrire 200 Go, le RAID 0 permettra d'écrire 100 Go sur chacun des disques. La théorie permet donc d'obtenir des performances 2 fois supérieures. Dans la pratique, avec l'utilisation de 2 disques, un gain de performance de 40% est excellent, à mettre en rapport avec les 50% attendus théoriquement.
Le RAID 0 est performant partout, en lecture et en écriture, qu’elles soient aléatoires mais surtout séquentielles. Pour tout ce qui concerne des lectures ou écritures aléatoires, si le contrôleur de disque supporte des lectures indépendantes sur les différents disques, on gagne à utiliser des bandes plus larges.
Il est à noter que les performances de l'ensemble des disques durs - taille, temps d'accès, ... - s'alignent sur le disque le plus faible. Ainsi, le disque le plus petit fixera la taille, le disque le plus lent fixera le temps d'accès, ... Cette restriction est applicable pour tous les autres niveaux de RAID à l'exception du JBOD.
Malgré ses excellentes performances, le RAID 0 n'est pas utilisé pour le stockage des données en milieu professionnel car il ne dispose pas de tolérance de panne.
Nous noterons les formules théoriques suivantes, en fonction du nombre de disques n :
- Nombre de disques au minimum : 2
- Espace disque : n * [Espace disque du plus petit des disques]
- Temps d'écriture : (1/n) * [Temps d'accès en écriture du plus lent des disques]
- Temps de lecture : (1/n) * [Temps d'accès en lecture du plus lent des disques]
- Tolérance de panne : 0
JBOD - Just a Bunch Of Disks...
Il s'agit d'une simple "concaténation" d'un ensemble de disques physiques pour former un disque logique plus important, et en aucun cas ne peut être considéré comme un RAID.
Nous noterons les formules théoriques suivantes, en fonction du nombre de disques n :
- Nombre de disques au minimum : 2
- Espace disque : [Somme de l'espace disque de l'ensemble des disques]
- Temps d'écriture : >=[Temps d'accès en écriture du plus lent des disques]
- Temps de lecture : >=[Temps d'accès en lecture du plus lent des disques]
- Tolérance de panne : 0
Nous noterons les formules théoriques suivantes, en fonction du nombre de disques n :
- Nombre de disques au minimum : 2
- Espace disque : [Somme de l'espace disque de l'ensemble des disques]
- Temps d'écriture : >=[Temps d'accès en écriture du plus lent des disques]
- Temps de lecture : >=[Temps d'accès en lecture du plus lent des disques]
- Tolérance de panne : 0
Inscription à :
Articles (Atom)
