Salut à tous,
 
A priori, ISCSI permet de stocker sur des baie de stockage ISCSI distante au travers du réseau IP classique.
Je sais que les perf seront forcéments moins bonnes qu'en FC (d(autant plus que notre réseau est en 100mbits). Mais est-il possible d'avoir un serveur physique avec 2 baies distantes (plusieurs centaines de km), le tout en raid?
Nous avons des VPN pour interconnecter nos réseaux et je me disais pkoi ne pas mettre une première baie disque à marseille, l'autre sur lyon et faire un RAID-1 dessus.
 
Sans tenir compte des perf du WAN est-ce possible? Que faut t'il comme matos?
 
D'avance merci

Par rapport a la distance, je pense pas que ca pose probleme, (f
FC => 2G c'est rai ca change.
Aprés faire le raid avec les baies separé comme ca je le sens vraiment pas.
si perte d'un lien via l'operateur aie.
si ralentissement réseaux le raid comment il le prend.
Si perte de paquets ==> FS corrompu ?
 
Je vois pas trop l'interet de separer les 2baies, pk pas le mettre dans la meme salle en FC (sur un blade non ?)
 
J'ai vu ca, mais sur ce type de demande  
faudrais mieux pas faire une demande chez un support pour etre sur
http://www.journaldunet.com/soluti [...] es/4.shtml

j'ai trouvé il te faut ca
 
FCIP (Fibre Channel over IP)
 
Le FCIP est aussi appelé Fibre Channel Tunneling ou Storage Tunneling. C'est un protocole permettant de créer un réseau SAN unique (fabric) à partir de deux SANs géographiquement distants.
Les trames FC sont encapsulées sous IP de manière transparente. On peut ainsi réaliser des sauvegardes ou des sites miroirs à plusieurs milliers de kilomètres de manière quasi-immédiate.
Ce système, simple, n'est pas sans inconvénients :
 
    * les différents réseaux d'origine sont confondus dans un ensemble unique,
    * les incidents de transmissions, gérés au niveau de chacune des deux normes (TCP/IP et FC), ne sont pas toujours réglés d'une manière souple et perf
 
jmettais pas trompé avec la perte de paquets lol

FCIP nécessite des réseaux performants.
Sur du WANoverVPN, tu oublies, tu vas avoir des perfs minables.
On parle d'IO disque là quand même, alors il faudrait veiller à etre un peu serieux.
En général, même si tu pars sur du iSCSI, du as quand même une NIC, voire un lan dédié au storage, pour avoir de bonnes performances. Faut pas rigoler avec les IO disque.
Ensuite, pour l'histoire du RAID 1, ce que tu veux faire c'est du host based mirroring : l'OS qui héberge les data se charge de faire le RAID sur les 2 baie, mais il doit accéder avec de bones perfs aux 2 baies. Après, ca dépend de l'OS. AIX, linux et Netware le font en standard. Pour windows, il faut des produits tiers, comme par exemple Storage foundation de symantec (le plus connu).
Sinon, tu peux aussi faire de la réplication Hardware (type PPRC chez IBM ou metrocluster chez netapp) mais la ca devient beaucoup plus touchy et cher (lan dédié à la réplication, scripts de basculement, licences, etc ...).
Sujet délicat, complexe, critique et pointu, à ne surtout pas prendre à la légère.
 -> faire synchroniser 2 baies de disques par un lien VPN sur aDsl est certes techniquement possible, mais pas viable pour la prod'.

c'est ça la subtilité. Si tes sites sont reliés en IPSEC dans l'internet laisse tomber.
 
Le FCIP est viable mais sur des liens performants. Des technos d'optimisation Wan (Cisco WAAS, Riverbed et autres...) peuvent beaucoup aider dans ce cas là sur les trafics volumineux et sensibles à la latence. Les consructeurs ont validés les solutions justement pour les réplications intersites
 
reste à voir ce que ça vaut en vrai, je n'ai jamais déployé ces solutions dans ce cadre très particulier.

Justement pas.
Dans le cadre de liens WAN, tous les optimizer de flux sont forts pour tout ce qui est commmunication en mode fichier (SMB, MAPI, ...) en optimizant le protocole de communication en question au caractéristiques particulière d'un environnement WAN, en particulier la latence plus que le débit lui-même (voir les différentes présentations -techniques évidemment - sur comment est optimisé SMB par bluecoat par ex. c'est assez parlant).
Avec le iSCSI, tu es en mode bloc, et dans ce cas précis, tu te fais assassiner par les latence, et le gain apporté par ton optimizer sera négligeable par rapport aux pertes de perfs engendrées par des IOdisk sur WAN.
Pas de miracle dans ce domaine.
En WAN, ce qui est possible en revanche, c'est les technologies de type DFS ou CCR (en fonction du service à fournir chez Microsoft) ou drdb/heartbeat sous linux.
Tu seras sujets aux perfs de ton WAN, naturellement, mais c'est une solution qui peut tenir la route.

SAN : Compaq joue la carte FCIP sur les liaisons intercontinentales
Compaq annonce la première infrastructure SAN intercontinentale (Australie, Pays-Bas, Etats-Unis), établie sur lien Fiber Channel sur IP (FCIP), en partenariat avec l'équimentier CNT pour la traduction des données.
 
Francisco Villacampa , 01net., le 26/09/2001 à 16h11
 
Compaq mise sur FCIP pour permettre le partage et l'administration de systèmes de stockage départementaux. Argument avancé pour barrer la route à son rival iSCSI ? La supériorité des connexions directes entres serveurs et les économies réalisées sur la répétition du signal.
 
Certes, les systèmes SAN dotés d'interfaces réseau Fast Ethernet (100 Mbit/s) ou Gigabit Ethernet (1 Gbit/s) sur liens Fiber Channel (FC) sont avantageux. Ces architectures permettent en effet de relier entre eux des systèmes de stockage distants de plusieurs kilomètres.
 
Problème. Sitôt que l'on dépasse la cinquantaine de kilomètres, les liens FC, établis sur de la fibre optique, nécessitent l'installation de répéteurs, destinés à prévenir une altération du signal. Lorsque l'on exploite du câble coaxial ou physiquement constitué de paires de cuivre, la distance entres deux répéteurs descend entre 1 et 10 kilomètres. Autre inconvénient pour les entreprises, le manque de compatibilité entre les différentes implémentations opérées par les fabricants dans les systèmes SAN.
 
Bref, le protocole n'est pas adapté aux liens longue distance entre réseaux départementaux. Sauf à utiliser de coûteux matériels d'amplification du signal.
 
iSCSI prétend résoudre ce problème en mariant le protocole TCP/IP côté transport et SCSI pour la commande à distance de périphériques chaînés. Mis au point par IBM, iSCSI permet le déploiement de systèmes SAN, ou de sous-ensembles de stockage NAS, reliés sur de longues distances. Côté avantages, le protocle iSCSI évite d'investir dans de coûteuses infrastructures Fiber Channel.
 
Compaq mise sur FCIP pour le SAN intercontinental
 
Pourtant, iSCSi n'est pas la panacée. Exploitée entres autres par Compaq sur ses systèmes SAN, FCIP permet également de partager et d'administrer des volumes distants à travers le protocole IP.
 
Avec des arguments de poids par rapport à iSCSI.
 
FCIP exploite Internet Protocol comme couche réseau n°3, servant de base au transport des paquets.
 
Cependant, il n'invoque pas les sessions TCP pour transporter les données d'un système de stockage à un autre, et ne fait pas non plus appel à des couches logicielles embarquées dans les baies de stockage pour reconvertir ces données. A l'image du VPN-IP, la traduction des données FC sur IP est physiquement effectuée en dehors du serveur, par des routeurs spécialisés.
 
Ainsi, FCIP maintient une continuité de service de système à système. Ces routeurs créent en effet un tunnel Fiber Channel sur couche IP, en liaison directe entre les contrôleurs des cartes réseaux.
 
Cela a pour effet de simuler l'existence d'un lien bidirectionnel entre machines. Du coup, une baie de stockage sur lien FCIP reste toujours visible, pour un serveur qui attend ces données, même en cas d'interruption d'une transmission Gigabit Ethernet.
 
Par ailleurs, FCIP économise répéteurs et multiplexeurs pour transmettre un signal sur de longues ditances, par rapport à une liaison FC classique.
 
FCIP se pose en rival de iSCSI
 
Aujourd'hui, le protocole FCIP est déjà présent dans les équipements de CNT, Gadzoox, Cisco (rachat de Nuspeed), Vixel ou Lucent. Pourtant, les fabricants à le proposer pour leurs solutions de stockage sont encore peu nombreux. IBM, EMC ou Hitachi préférant en effet le iSCSI ou le FC classique.
 
Seule certitude, Compaq compte se servir de FCIP pour barrer la route aux acteurs du SAN longue distance. L'offre de stockage virtualisé ENSA-2 (Enterprise Network Storage Architecture 2) devrait être la première à être établie sur ce type de liens.
 
Dans le temps de cette annonce, les acteurs du projet SAN Promontory (Adaptec, Dell, Hitachi Data Systems, IBM, Intel, QLogic et Qwest Communications) se sont empressés de démontrer que le protocole d'IBM était également mûr pour l'administration très longue distance.
 
Une expérimentation réussie, vient d'être réalisée entre les deux côtes des Etats-Unis, à des débits pratiques de 2,5 Gbit/s, sur un lien iSCSI de 10 Gbit/s.  
http://www.01net.com/article/161188.html

arf, j'ai donc négligemment fait confiance aux pres marketing (sur lesquelles ils mettent que ça aide pour les réplications de baies)

Double Take ne serait pas une bonne solution ?