Je ne vois aucune raison de ne pas utiliser des disques SSD SAS plutôt que des disques durs SAS. Toutefois, si l'on a le choix entre un SAS HDD et un SATA SSD, mon choix d'entreprise pourrait bien être le disque SAS.
Raison : SAS a une meilleure récupération des erreurs. Un disque dur SATA d'édition non-RAID pourrait bloquer tout le bus (et par conséquent refuser l'utilisation de tout le serveur) lorsqu'il meurt. Un système basé sur SAS ne perdrait qu'un seul disque. S'il s'agit d'un disque dans une matrice RAID, rien n'empêche d'utiliser le serveur jusqu'à la fin de l'activité, puis de remplacer le disque.
Notez que ce point est discutable si vous utilisez des disques SSD SAS.
[J'ai essayé de mettre ceci dans un commentaire mais je n'ai pas de balises.
Je n'ai jamais dit que le contrôleur SAS se connectera à un autre disque. Mais il gérera les défaillances de manière plus gracieuse et les autres disques sur le même fond de panier resteront accessibles.
Exemple avec SAS :
SAS HBA ----- \[Backplane\]
| | | |
D1 D2 D3 D4
Si un disque tombe en panne, il sera abandonné par le HBA ou la carte RAID.
Les 3 autres disques sont en bon état.
En supposant que les disques soient dans une matrice RAID, les données seront toujours là et resteront accessibles.
Maintenant avec SATA :
SATA ----- \[port multiplier\]
| | | |
D1 D2 D3 D4
Un lecteur tombe en panne.
La communication entre le port SATA de la carte mère et les trois autres lecteurs risque de se bloquer. Cela peut se produire parce que soit le contrôleur SATA se bloque, soit le multiplicateur de port n'a aucun moyen de récupérer.
Bien que nous ayons encore 3 disques en état de marche, nous n'avons aucune communication avec eux. Pas de communication signifie pas d'accès aux données.
Il n'est pas difficile de mettre hors tension et de retirer un disque cassé, mais je préfère le faire en dehors des heures de bureau. Avec SAS, il est plus probable que je puisse le faire.