La Fibre
Datacenter et équipements réseaux => Équipements réseaux => 
NAS, serveurs et micro-serveurs => Discussion démarrée par: vivien le 04 septembre 2015 à 08:15:46
-
Différences entre disques SAS et disques SATA
J'ai découvert dans les commentaires d'un article de Linuxfr "Et si la meilleure des cartes RAID était libre ? (http://linuxfr.org/news/et-si-la-meilleure-des-cartes-raid-etait-libre)" une explication intéressante que je vous partage :
Si le but est d'avoir un sync rapide, et de la mémoire cache en écriture pléthorique, cela ne doit pas être difficile de mettre 1 Go de ram de cache d'écriture sur un disque dure au lieu de 32 Mo et d'avoir une super capacité pour finir un fsync en cas de coupure d'alimentation.
C'est pas tout à fait aussi simple que ça. Le disque dur doit en plus posséder une intelligence au niveau bloc (au minimum). Si tu fais du sync brut de fonderie tu vas à la catastrophe, si tu fais du sync en mode pur synchrone tu tues les perfs.
Par exemple tu copies un gros fichier comme copie d'un autre, puis tu modifies le nouveau fichier en changeant un caractère et tu modifies l'ancien fichier en changeant un autre caractère.
Si tu n'as pas d'intelligence au niveau bloc il va se produire un des deux scénarios suivant :
1) Mode synchrone pur
- demande de copie du fichier => "Ouhlà gros fichier,on va syncer plus tard"
- modification du nouveau fichier => "Bon ben on va syncer maintenant, merci de patienter le temps de la copie, pas touche au fichier en attendant"
- modification de l'ancien fichier => "Bon ben on va syncer maintenant, merci de patienter le temps de la copie, pas touche au fichier en attendant"
Conséquence : gros impact sur les I/Os notamment en cas d'accès concurrents. L'OS peut faire des pirouettes pour permettre la modification de l'ancien fichier alors que le nouveau n'est pas encore copié, mais au niveau disque c'est clairement pas top. (Et pourtant c'est ce qui se passe 90% du temps en SATA….)
2) Mode "brut de décoffrage"
- demande de copie du fichier => "Ouhlà gros fichier, on va syncer plus tard"
- modification du nouveau fichier => "Bon ben on va syncer maintenant, merci de patienter le temps de la copie, pas touche au fichier en attendant"
- modification de l'ancien fichier => "Un seul caractère ? Pas de problème gars - on fait ça tout de suite"
Conséquence : impact modéré sur les I/O, mais gros risque de corruption de données si la source du fichier en cours de copie est modifié.
En SAS (et en scsi en général) il va se passer ça (en ultra simplifié hein…) :
demande de copie du fichier => "Les blocks Xxxx,Xxxy,….Xzzz sont faux, à la place utiliser les blocks Yxxx,Yxxy,….Yzzz en lecture"+" Planifier copie des blocs Yxxx,Yxxy,….Yzzz vers Xxxx,Xxxy,….Xzzz"
Modification du nouveau fichier => "Le bloc Xzxy est faux à la place utiliser cache Xaab" + "Anuler copie du bloc Yzxy vers bloc Xzxy"+"Planifier copie du bloc cache Xaab vers bloc Xzxy"
Modification de l'ancien fichier => "mettre en cache dans Xaad le bloc Yzyy" + "Le bloc Yzyy est faux à la place utiliser bloc cache Xaac" + "Le bloc Xzyy est faux à la place utiliser bloc cache Xaad"+"Planifier copie du bloc cache Xaac vers le bloc Yzyy"+"Annuler copie bloc Yzyy vers Xzyy"+"Planifier copie du bloc cache Xaad vers Xzyy"
Au niveau I/O, temps de réponses, opérations à effectuer pour un sync etc. on comprend assez vite que le SAS va booster grave.
Bien entendu il y a en plus des algos qui font que les écritures proches sont faites par lot, la gestion du cache est beaucoup plus puissante que ce qu'exposé dans cet exemple simpliste etc.
En SATA, la nature même du fonctionnement fait que le cache s'essouffle très vite. Il y a eu à une époque des disque SATA avec 256Mo, mais leurs perfs étaient à peine meilleure que les disques avec 32Mo. Honnêtement sauf à ballader à longueur de journée des fichiers qui font la moitié de la taille du cache disque, il n'y a aucun intérêt à aller au delà de 64Mo en SATA, et déjà c'est overkill…
Source : LinuxFR (http://linuxfr.org/news/et-si-la-meilleure-des-cartes-raid-etait-libre) Posté par Kaane le 10/02/14
-
Bah, un truc qui boost les performances, c'est l'IO cache de l'OS
-
Ouais sauf qu'à un moment il faut bien écrire sur disque ce que tu as caché en RAM.
Et là le SCSI/SAS fait toute la différence avec le SATA. L'auteur du post ne précise pas non plus que le SCSI/SAS décharge le CPU de toutes les opérations de gestion des ordres aux disques, au contraire du SATA qui est "piloté" par le CPU.
J'ai (encore) du SCSI à la maison avec des disques de 36Go et 72Go en 10000 et 15000rpm, la différence est impressionnante. Sur des machines anciennes c'est encore plus visible.
Par contre, la différence de prix est un peu rédhibitoire !
-
article très intéressant!
je ne connaissais pas le fonctionnement je me coucherais moins bête ce soir :P
-
Ben en fait le SAS est une techno tres utilisée sur les seveurs pro, le SATA c'est plutot destiné aux PC grand publique.
-
ça empêche pas d'utiliser du sata dans le pro aussi ;)
si tu as pas besoin de perfs de malade sur le disque autant partir sur du sata!, tu pourras mettre plus de budget ailleurs!
pour de la sauvegarde morte typiquement ça pourrait être intéressant.
-
J'ai pas dit de les disques SATA était moins performent, maintenant si tu regarde ce qui ce qui est utilisé sur tous les servers IBM, Dell: HP et autres c'est des disques SAS.
Pourquoi je sais pas.
-
LaFibre.info, c'est un serveur Dell PowerEdge R210 II, mais un disque Sata de 500 Go. Il y a peu d'E/S disque, ce n'est pas un serveur de fichier.
De nombreux acteurs (Netflix, Google) partent aussi sur des disques Sata peu cher snas Raid avec une redondance gérée plus bas. (Pour netflix : disque perdu => un autre serveur du cache prend le relai pour les données perdues, qui sont présents sur plusieurs caches)
-
NetApp et EMC2 vendent aussi des tiroirs en disques SATA 7200rpm, c'est bien moins cher et largement suffisant pour beaucoup de besoins.
Beaucoup de serveurs d'entrée de gamme sont en SATA d'origine, ça n'a rien de choquant, une fois l'OS bouté OSEF du disque. Et pour les BDD ou les gros hyperviseurs, on utilise le SAN donc les disques locaux...
A noter qu'un controleur SAS reconnait un disque SATA (le connecteur est identique) mais pas l'inverse.
-
Ben pour les bays de disc HP j'ai vu que des disques SAS, en voila un qui vient de mourrir.
(http://s11.postimg.org/pv8icu943/sas.jpg)
-
C'est parce que HP c'est à peine du mid-end en SAN -> Netapp/EMC utilisent des disques natifs FC :)
-
En fait les bay de stockage HP c'est des HItachi, c'est pas eux qui les font, mais probablement que EMC c'est la meme chose, c'est aussi du matos que je connais.
-
NetApp=maison, meme l'OS
EMC2=maison (meme les alims et les onduleurs intégrés) par contre l'OS c'est... du Windows.
Hitachi j'en ai aussi mais je ne sais pas dire.
HP ça m'étonne que ça soit de l'Hitachi ça ne se ressemble pas beaucoup.
IBM revend du NetApp en NAS et c'est du maison en SAN.
-
Petit comparatif des performances entre disques dur qui ont une taille d'environ 80 Go
- Utilitaire : UDisks 2.1.5 / gnome-disk-utility 3.14.0 (paramètres par défaut) sous Ubuntu 15.04 64bits (Kernel Linux 3.19)
- Contrôleur utilisé pour les disques SATA: Intel Corporation 8 Series/C220 Series Chipset Family 6-port SATA Controller avec CPU Intel Core i3-4150 @3.50GHz
- Contrôleur utilisé pour les disques SAS en RAID1 (Disques en miroir) : RAID bus controller: Adaptec AIC9580W AAC-RAID 4 ports SAS LVD appelé IBM ServeRAID 8k-l qui inclut un cache de 32Mo de DDR PC2-4200 avec CPU Intel Xeon E5430 @2.66GHz
73,4 Go SAS IBM-ESXS
Vendor: IBM-ESXS
Product: ST373455SS
Revision: BA26
User Capacity: 73 407 488 000 bytes [73,4 GB]
Block size: 512 bytes logical
Livré avec: Serveurs IBM System x3550
Format de Disque: 3" 1/2
Interface: SAS (SPL-3) LVD (low-voltage differential)
Date fabrication: Mai 2008
Vitesse rotation: 15015 TPM
Consommation max: 18,2w (1,00A x 5v + 1,10A x 12v)
(https://lafibre.info/images/materiel/200805_disque_dur_SAS_IBM-ESXS_System_x3550.png)
80 Go SATA Maxtor DiamondMax 10
C'est un disque dur de serveur HP entrée de gamme à 7200 tr/min. Ce qui est étonnant, c'est sa consommation maximum qui dépasse celle du disque SAS 15015 tr/min
Model Family: Maxtor DiamondMax 10
Device Model: Maxtor 6L080M0
Firmware Version: BACE1GG0
User Capacity: 80 026 361 856 bytes [80,0 GB]
Sector Size: 512 bytes logical/physical
ATA Version is: ATA/ATAPI-7 T13/1532D revision 0
Livré avec: Serveurs HP ProLiant
Format de Disque: 3" 1/2
Interface: Serial ATA 1,5 Gb/s
Date fabrication: Juin 2006
Vitesse rotation: 7200 TPM
Consommation max: 21,7w (0,74A x 5v + 1,50A x 12v)
(https://lafibre.info/images/materiel/200606_disque_dur_SATA_Maxtor_DiamondMax_10.png)
-
82,3 Go SATA Hitachi Deskstar 7K80
Model Family: Hitachi Deskstar 7K80
Device Model: HDS728080PLA380
LU WWN Device Id: 5 000cca 30ce679fa
Firmware Version: PF2OA6BA
User Capacity: 82 348 277 760 bytes [82,3 GB]
Sector Size: 512 bytes logical/physical
ATA Version is: ATA/ATAPI-7 T13/1532D revision 1
Livré avec: Serveurs SUN SunFire
Format de Disque: 3" 1/2
Interface: Serial ATA
Date fabrication: Avril 2006
Vitesse rotation: 7200 TPM
Consommation max: 10,3w (0,62A x 5v + 0,60A x 12v)
(https://lafibre.info/images/materiel/200604_disque_dur_SATA_Hitachi_Deskstar_7K80.png)
80 Go SATA Western Digital Caviar SE (modèle de mai 2006)
Les débits sont meilleur sur ce modèle de 2006 vs sur celui de 2005 (ci-dessous)
Par contre les temps d’accès sont moins bon sur le modèle 2006 vs sur celui de 2005 (ci-dessous)
Model Family: Western Digital Caviar SE Serial ATA
Device Model: WDC WD800JD-75MSA2
Firmware Version: 10.01E03
User Capacity: 80 000 000 000 bytes [80,0 GB]
Sector Size: 512 bytes logical/physical
ATA Version is: ATA/ATAPI-7 (minor revision not indicated)
Livré avec: Serveurs Dell PowerEdge
Format de Disque: 3" 1/2
Interface: Serial ATA
Date fabrication: Mai 2006
Vitesse rotation: 7200 TPM
Consommation max: 8,25w (0,45A x 5v + 0,50A x 12v)
(https://lafibre.info/images/materiel/200605_disque_dur_SATA_Western_Digital_WD800JD.png)
80 Go SATA Western Digital Caviar SE (modèle de mai 2005)
Model Family: Western Digital Caviar SE Serial ATA
Device Model: WDC WD800JD-75JNC0
Firmware Version: 06.01C06
User Capacity: 80 000 000 000 bytes [80,0 GB]
Sector Size: 512 bytes logical/physical
ATA Version is: ATA/ATAPI-6 (minor revision not indicated)
Livré avec: Serveurs Dell PowerEdge
Format de Disque: 3" 1/2
Interface: Serial ATA
Date fabrication: Mai 2005
Vitesse rotation: 7200 TPM
Consommation max: 8,25w (0,45A x 5v + 0,50A x 12v)
(https://lafibre.info/images/materiel/200505_disque_dur_SATA_Western_Digital_WD800JD.png)
-
J'ai pas dit de les disques SATA était moins performent, maintenant si tu regarde ce qui ce qui est utilisé sur tous les servers IBM, Dell: HP et autres c'est des disques SAS.
Sur les serveurs, Dell en particulier, on trouve aussi pas mal de Nearline SAS, c'est à dire de disques SATA entreprise (7200 rpms) à interface SAS. C'est un bon compromis entre prix, capacité et performances. Les disques SAS ont de meilleures performances (10k, 15k), sont plus fiables, mais de moindres capacités et des prix nettement plus élevés.
Edit : Une petite référence :
http://www.techrepublic.com/blog/data-center/how-sas-near-line-nl-sas-and-sata-disks-compare/
-
En fait HP fabrique les bay de storage comme la serie MSA mais c'est pas pour des tres grosse capacité, les gros modèle c'est du Hitachi avec le logo HP dessus , la serie XP par exemple
(http://s10.postimg.org/8hv8fibjd/storage.jpg)
-
@miky01
HP a racheté 3Par en 2010. Les baies généralistes grosses capacité du catalogue HP sont actuellement des 3Par Storeserv en 8000 et 20000.
Ils semblent proposer les XP7 uniquement en "mission critical".
Attention, cela recouvre à la fois des baies mixtes (plusieurs techno de disques) et des baies dédiées flash.
Je ne savais pas que les XP étaient du HDS rabadgé, le commercial ne les abordes pas quand tu es client potentiel des 20000.
-
Les 3Par c'est surtout pour les bays flash disc, je sais pas si c'est dispo pour les tres grosse capacités de stockage. ?
-
Ce n'est qu'une question de montant du chèque que tu es pret à signer.