Le protocole
Résultat, le
Si jamais vous envisagez de lire le RFC entier, je vous souhaite
bon courage. Si vous voulez juste apprendre deux ou trois choses sur
iSCSI, révisez d'abord un peu
SCSI peut aussi être utilisé pour parler à des
Les commandes sont regroupées en tâches. Chaque tâche est séquentielle (une commande après l'autre) mais un initiateur et une cible peuvent avoir plusieurs tâches en cours d'exécution parallèle.
Les données peuvent évidemment voyager dans les deux sens : si un ordinateur écrit sur un disque, l'initiateur (l'ordinateur) envoie des données à la cible (le disque). Si l'ordinateur lit un fichier, ce sera le contraire, les données iront de la cible vers l'initiateur. Le sens de voyage des données est toujours exprimé du point de vue de l'initiateur. Donc, du « trafic entrant » désigne des données allant de la cible vers l'initiateur (une lecture sur le disque, par exemple).
iSCSI consiste à envoyer les messages SCSI, baptisés PDU (pour
La réponse à une commande donnée doit être envoyée sur la même connexion TCP que celle où la commande avait été reçue (« allégeance à la connexion »). Ainsi, si un initiateur demande une lecture de données, celles-ci arriveront sur la même connexion.
L'ordre des commandes est parfois essentiel en SCSI. Pour cela,
elles sont numérotées (
À noter que les réponses aux commandes, en SCSI (et donc en iSCSI), ne respectent typiquement aucun ordre. Si une cible exécute la commande A puis la commande B, la réponse à B pourra arriver à l'initiateur avant la réponse à A (ce qui est logique, les opérations d'entrée/sortie pouvant avoir des durées très variables ; la commande B était peut-être très rapide à exécuter).
Les données, elles, ont un ordre. Si on lit 10 000 octets, on veut
évidemment recevoir le premier octet des données en premier. D'où le
Un autre point important : TCP fournit un service de flot d'octets
continu. Il n'y a pas de séparation entre les PDU (les messages) iSCSI. Pour que le
destinataire puisse donc savoir où se termine le PDU (et où commence
le suivant), ceux-ci sont préfixés par leur longueur (comme dans
beaucoup d'autres protocoles utilisant TCP, par exemple dans
Les données peuvent être sensibles (confidentielles, par exemple)
et iSCSI doit donc prévoir des mécanismes d'authentification. Ainsi,
au début d'une session, l'initiateur se présente et prouve son
identité. La cible doit aussi prouver qu'elle est bien la cible visée
(authentification mutuelle). Il existe plusieurs mécanismes pour cela,
décrits en détail en sections 6 et 12. La recommandation de ce RFC est de
protéger les sessions avec
Au fait, comme toujours en réseau, il faut des identificateurs pour
désigner cibles et initiateurs. En iSCSI, il sont appelés
iSCSI fournit trois formats pour atteindre
ces objectifs. Un nom commence par un type indiquant quel format est
utilisé, puis comprend le nom proprement dit. Les trois types sont :
Il existe également des mécanismes de découverte des noms
accessibles, décrits dans les
Attention, ce
iSCSI est décrit par une
Évidemment, les disques durs peuvent tomber en panne ou bien le réseau entre l'initiateur et la cible partir en vacances. Il faut donc prévoir des mécanismes de gestion des erreurs, et ils font l'objet de la section 7. C'est ainsi que, par exemple, une tâche qui échoue sur une connexion TCP peut être reprise sur une autre (qui peut passer par un chemin réseau différent). Notez que cette norme n'impose pas aux acteurs iSCSI de tous mettre en œuvre des techniques sophistiquées de récupération d'erreurs, juste de réagir proprement lorsque les erreurs se produisent. La section 7 est très détaillée : après tout, on ne veut pas perdre ses précieuses données juste parce que l'Internet a eu un hoquet pendant une opération d'écriture en iSCSI.
Mais comment détecte-t-on un problème sur une connexion TCP ? Cela
peut être un message
Les pannes, c'est ennuyeux, mais les piratages, c'est pire. On ne
veut pas qu'un méchant situé sur le trajet puisse lire nos données
secrètes ou modifier ce qu'on écrit sur le disque. En SCSI
traditionnel, une grande partie de la sécurité est physique :
initiateur et cible sont dans le même boîtier (celui du serveur) ou à
la rigueur dans la même
iSCSI peut être utilisé sans sécurité, comme l'ancien SCSI, si on
est parfaitement sûr de la sécurité physique. Mais notre RFC
déconseille de courir ce risque. iSCSI fournit deux mécanismes de sécurité et le
RFC demande qu'on les utilise. Le premier est interne à iSCSI, c'est
l'authentification réciproque des deux parties lors de l'établissement
de la session. Le deuxième est externe, et c'est
À noter qu'une limite d'IPsec est que les systèmes d'exploitation
typiques ne permettent pas à une application de savoir si ses
connexions sont protégées ou non par IPsec. Ainsi, une application qui
voudrait faire une authentification par mot de passe en clair
uniquement si la connexion est chiffrée ne peut pas être sûre et doit
donc supposer le pire (une connexion non chiffrée). L'authentification
interne ne doit donc jamais utiliser de mot de passe en clair. La
méthode recommandée est
Le mécanisme interne n'assure que l'authentification réciproque. Il ne protège pas contre l'écoute, ni même contre la modification des messages en cours de route. Il ne doit donc être utilisé seul que si on est sûr que ces écoutes et ces modifications sont impossibles (par exemple si on a une bonne sécurité physique du réseau). Imaginez les conséquences d'une modification des données avant leur écriture sur le disque !
IPsec dans iSCSI doit suivre le
Les programmeurs tireront profit de la section 10, qui rassemble
des conseils utiles pour mettre en œuvre iSCSI sans se planter. Un des
enjeux de iSCSI est la performance, vu les grandes quantités de
données à traiter... et l'impatience des clients. Le protocole a été
soigneusement conçu pour permettre d'éventuelles implémentations
directement dans le matériel, et pour permettre le DDP
(
Parmi les points notés par cette section, la gestion des machines
dotées de plusieurs cartes réseau (on peut en utiliser plusieurs pour
la même session iSCSI), le délicat choix des délais
d'attente maximaux (non normalisés, car dépendant de
l'infrastructure, notamment matérielle), et l'ordre des commandes (une
commande qui change l'état de la cible, par exemple un vidage
-
La section 11 décrit le format exact des PDU sur le câble. Si vous le désirez, on trouve des traces iSCSI sur pcapr.
Il existe de nombreuses mises en œuvre d'iSCSI et des programmeurs
de nombreuses entreprises (
À part le gros changement éditorial (consolider plusieurs RFC en un seul), les changements de iSCSI dans ce RFC sont peu nombreux. Par exemple, une stricte prohibition des caractères de ponctuation dans les noms SCSI est devenue une forte mise en garde. La section 2.3 liste toutes les modifications.
Merci à Bertrand Petit pour sa relecture attentive.