Les SAN ?
Storage Array Network ou des systèmes de stockage à base de 'tableaux' de disques.
On voit de plus en plus ces animaux Hard/soft dans les entreprises moyennes et grandes car ils permettent de gérer plus facilement le stockage de grands volumes avec pas mal de possibilités telles que le mirroring, le hot plug la recopie à chaud de disques, la ventilation sur n disques ,etc..
A ne pas confondre avec les NAS Network Area Storage qui sont des unités de stockage accessibles via le réseau.
Pour ce qui concerne les SAN, je connais deux modes de communications :
- Par fibre optique (Fibre Channel) qui sont les systèmes les plus rapides mais aussi les plus coûteux : dans ce cas du matériel spécifique connecte les UC et le SAN
- Par réseau TCP/IP sous la forme ISCI qui fait passer des trames SCI au travers de IP : avantages : coût et matériel standard.
N'ayant pas les moyens de mettre 30000 € dans un SAN FC je vais me contenter d'une maquette à base de iSCSI…
Pour cette maquette il me faut les deux parties :
- Le serveur SAN
- La couche client iSCSI qui porte le nom d'initiator dans le monde Windows
Le serveur SAN iSCSI :
Il existe bien sûr des engins tout faits sur le marché, mais, là encore, les premiers prix (3000 €) sont hors de mon budget pour cette maquette.
Je me suis donc retourné vers une solution soft à base de Windows Server 2003 R2, ce qui tombe bien, j'avais mon ancien serveur qui ne faisait rien…
La société StarWind a développé des SAN à base de soft et fournit heureusement une solution gratuite à des fins d'expérimentation :
Voici son URL :
http://www.starwindsoftware.com/free-products
Après installation du logiciel et de sa licence (voir la documentation fournie), passons à la configuration de notre SAN logiciel :
Il faut ajouter un hôte :
L'adresse de bouclage fera l'affaire...
On peut maintenant se connecter à cet hôte :
On voit bien sur l'image ce que je veux faire :
- Un serveur SAN
- Un serveur SQL avec accès au SAN
- Et, dans un 3ème temps, un accès au SAN via VMWare
Le mot de passe par défaut est starwind
Il reste maintenant à créer les cibles, c'est à dire les disques logiques :
Je choisis 100 Go pour ce 1er disque physique (le logiciel d'évaluation gère jusqu'à 2To)
Je procède de la même manière pour créer un 2ème disque physique sur ma 2ème unité locale
en effet, il y a deux disques physiques sur ce serveur SAN :
Cette fois ci, la taille est de 200 000 Mo.
Afin de simuler des disques à haute vitesse, je crée maintenant un disque RAM de 1Go :
Voici le récapitulatif de ma configuration SAN logiciel :
La configuration de mon SAN est terminée !
La société StarWind ne ment pas quand elle annonce 10 minutes pour créer un petit SAN … ce logiciel est vraiment simple de manipulation.
Le driver iSCSI :
Sous Windows Server2008 ce driver (appelé iSCSI Initiator) est natif, par contre sur Windows 2003 Server (une des mes cibles) il faut le télécharger ici :
http://www.microsoft.com/downloads/details.aspx?familyid=12CB3C1A-15D6-4585-B385-BEFD1319F825&displaylang=en
Installation de Initiator sous Windows Server2003 :
Après installation du logiciel, celui-ci est visible dans le panneau de configuration :
Je me sers ici de l'initiator avec mon adresse de bouclage (voir plus loin formatage des unités logiques)
On voit ici mes 2 unités logiques après formatage.
Installation des disques logiques sur une machine Windows Server 2008 :
Comme dit avant, le connecteur est déjà installé sur WindowsServer2008, il suffit de le configurer :
L'adresse IP de mon SAN…
J'ai ouvert 3 sessions sur les disques logiques de mon SAN.
Je peux maintenant ajouter ces 3 disques à mon serveur :
Je viens ici d'initialiser mes 3 disques :
Il reste bien sûr à les formater :
Hélas, cela semble prendre des heures…
Je décide donc de stratégie et installe l'initiator sur la machine SAN, après avoir pris soin de déconnecter les unités de ma machine hôte (on ne peut pas dans cette configuration y accéder à plusieurs)
Ce qui me permet d'accéder à mes unités par l'adresse de bouclage (en local donc) et là, miracle !
Le formatage de 200 Go demande moins d'une minute !
Je n'ai plus qu'à faire la manœuvre inverse :
- Détacher mes unités de l'initiator local
- Les rattacher sur le site distant
C'est tout bon ! Mes unités apparaissent bien formatées et donc prêtes à recevoir des données.
Passons maintenant aux tests avec SQLServer dans plusieurs configurations.
Protocole de tests sur SQLServer2008 :
Voici mes 3 disques montés et formatés :
G : mappé sur le disque physique 1 de mon serveur SAN
H : mappé sur le disque physique 2 de mon serveur SAN
I : mappé sur un disque RAM de mon serveur SAN : me permettra de simuler un disque à haute vitesse
Voici le script de création de la base de tests :
-- =============================================
-- La base de test avec différents scénarios
-- =============================================
IF
EXISTS
(
SELECT
*
FROM
sys.databases
WHERE
name
=
N'DemoIScsi'
)
DROP
DATABASE
DemoIScsi
GO
CREATE
DATABASE
DemoIScsi
ON
PRIMARY
(NAME
=
FichierDeDonnees,
FILENAME
=
N'D:\DemoIScsi.mdf',
SIZE
= 10MB,
MAXSIZE
= 50MB,
FILEGROWTH
= 10%)
LOG
ON
(
NAME
=
FichierJournal,
FILENAME
=
N'D:\DemoIScsi.ldf',
SIZE
= 10MB,
MAXSIZE
= 500MB,
FILEGROWTH
= 10%)
GO
Et celui des tests de performances :
use
DemoIScsi
go
if
exists
(select 1 from
INFORMATION_SCHEMA.TABLES
where
TABLE_NAME
=
'Produits')
drop
table
Produits
go
create
table
Produits
(IdProduit
int
identity (1,1)
primary
key,
Nom
char(1000)
)
-- C'est volontairement MAUVAIS...
go
-- Mesure de perfs en INSERT (soit 20 Mo)
declare
@i
int
set
nocount
on
set
@i
= 1
while
@i
< 20000
begin
insert
into
Produits
(Nom)
values (REPLICATE('A',1000))
set
@i
=
@i
+ 1
end
go
-- Mesure de perfs en UPDATE (pour charger le LOG)
update
Produits
set
Nom
=
REPLICATE('B',500)
-- Mesure de perfs en SELECT
select
COUNT(*)
from
Produits
where
Nom
like
'AA%'
-- Mesure de perfs en DELETE
delete
from
Produits
use
master
go
Et le résultat des courses :
Fichier Base | Fichier LOG | INSERTs | UPDATEs | SELECTs | DELETEs |
Local | Local | 10 secs | 4 secs | 1 sec | 4 secs |
Distant SAN2 (2) | Local | 9 secs | 3 secs | 1 sec | 2 secs |
Distant SAN2 (3) | Distant SAN1 | 23 secs | 9 secs | 1 sec | 7 secs |
Distant SAN2 (4) | Distant RAM | 18 secs | 9 secs | 1 sec | 7 secs |
Distant SAN2 (5) | Distant SAN2 | 25 secs | 9 secs | 1 sec | 9 secs |
Décodage :
(2) On a ici les meilleures performances car on est dans les bonnes pratiques du DBA , à savoir séparation du LOG et de la base
Par contre, il est clair que le réseau sera chargé lors des checkpoint, et que, si on insiste beaucoup on pourrait arriver à un ralentissement de ces CHECKPOPINT et donc une famine des pages en RAM.
On voit ici le passage des CHECKPOINT et leur influence sur le réseau :
On voit nettement que des CHECKPOINT ont pu saturer le réseau à 100%
Cette configuration demande donc (mais tous les SAN) quelque chose de costaud pour la connexion entre le SAN et le serveur SQL
Les techniques que l'on voit dans cet ordre :
- Utilisation de hard spécifique avec fibre optique (sortir les billets de 10000)
- Passage à un réseau Gbits (celui de ma démo n'est qu'en 100 Mbits)
- Multiplication des cartes réseaux en attribuant un port à chacune
(3) On est dans la plus mauvaise situation, l'ensemble des IO passant au travers du réseau, toutefois la ventilation sur deux disques physiques reste nécessaire…comme le montre le cas (5)
(4) Ce cas permet de voir l'incidence d'un disque très rapide dans le SAN :
On voit qu'il y a quelques performances à gagner et on peut en conclure que :
- Les disques à 15000 tours/min
- Les disques SSD (Single State Drive) soit des disques en RAM
Ne devraient pas rester dans les placards !
(5) Le pire des cas , toutes les IOS passant par le réseau, et avec, en plus une contention sur le disque unique dans le SAN.
Ne laissez pas vos administrateurs SAN tout mettre sur le même disque par souci de simplification !
Au contraire, profitez de la puissance du SAN pour ventiler (Log et Base), (Groupe en lecture, en mise à jour) (Tables partitionnées) …etc.
La colonne SELECT n'est pas significative car le buffer de données jouant son rôle, il n'y a pas d'accès disque….
Dernier test : utilisation du SAN avec VMWARE
Ma VM étant sur du 2003 Server, je dois d'abord installer l'initiator iSCSi.
Je fais d'abord un jeu de test en local (c'est-à-dire que mon disque traverse la VM pour atteindre celui du host)
Et le résultat des tests :
Fichier Base | Fichier LOG | INSERTs | UPDATEs | SELECTs | DELETEs |
Local via VM (1) | Local via VM | 14 secs | 7 secs | 2 secs | 5 secs |
Distant SAN2 (2) | Local | 13 secs | 7 secs | 1 sec | 3 secs |
Distant SAN2 (3) | Distant SAN1 | 26 secs | 9 secs | 1 sec | 7 secs |
Distant SAN2 (4) | Distant RAM | 17 secs | 9 secs | 1 sec | 8 secs |
Distant SAN2 (5) | Distant SAN2 | 28 secs | 9 secs | 1 sec | 9 secs |
Décodage :
- On voit clairement le coût de la virtualisation : pas de miracle, la traversée des couches se paie…
- Les meilleurs temps de réponse : si on a un bon réseau/fibre
- L'émulation de la carte réseau coûte aussi, mais j'utilise ici VMWare player, les versions commerciales de VMWare doivent mieux faire
- Bon mais moins que le log en local
- Comme toujours la pire des situations : à éviter !
Conclusion :
Bien que les SAN aient le vent en poupe, je pense qu'une machine avec des disques locaux/très rapides l'emportera toujours en termes de performance pure….pour ce qui est de la simplicité d'administration , c'est un autre débat !