Macierze pamięci masowej w podsieci GbE („docelowe”)

Firma Cisco sprowadziła FCIP (oczywiście nieoficjalnie) do funkcji środka taktycznego. Korzyści płynące z jego stosowania były oczywiste: najistotniejszą była możliwość podwójnego wykorzystania infrastruktury IP, zarówno dla przenoszenia pamięci masowej, jak i komunikatów sieci LAN. Równie oczywiste były jednak także nieodłączne wady protokołu: połączenie dwóch lub więcej wysp SAN przy użyciu FCIP tworzyło odpowiednik jednej olbrzymiej SAN. Prowadziło to do utraty lokalnej tożsamości wysp. W procesie łączenia struktur przy użyciu tej metody klient ponosił ryzyko, że infrastruktury zupełnie przestaną funkcjonować. Ta sama kwestia, która powodowała ból głowy u techników przy wdrożeniach lokalnych infrastruktur wieloprzełączni- kowych — można tu wymienić różnorakie kłopoty, od trudności we współdziałaniu przełączników i niezgodnych metod podziału na strefy aż do problemów i ograniczeń związanych z oprogramowaniem wbudowanym adapterów HBA i ograniczeniami — pojawiała się w trakcie łączenia zdalnych struktur w opartych nalP sieciach lokalnych, miejskich lub rozległych (LAN, MAN lub WAN). Odległości wiążące się z ogólną infrastrukturą komplikowały rozwiązanie problemu.

Niezależnie od tych niedogodności, prace postępowały i stworzono protokół FCIP, obsługiwany przez przełącznik typu blade firmy Cisco Systems, a następnie IETF wydało RFC. Zaledwie osiemnaście miesięcy później stosunki między Cisco Systems a Brocade Communications Systems zostały zerwane, z całą zajadłością rozwodu w hollywoodzkim stylu.

Kierownictwo Cisco wpadło w szał, gdy w Brocade celowo skonstruowano protokół, który był zgodny tylko z własnymi przełącznikami Fibrę Channel tej firmy. Każda z firm poszła swoją drogą, choć — co również jest zgodne z wspomnianym już „hollywoodzkim stylem” — żadna nie była skłonna oddać „nazwiska” (Systems).

W przeciwieństwie do FCIP, iFCP był protokołem bronionym przez kadrę dostawców, którzy zabiegali o połączenie świata FCP ze światem IP, wprowadzając pojęcie bramy IP-FCP. To rozwiązanie postrzegane było jako bardzo praktyczne przez firmy takie jak Nishan Systems było ono zapowiedzią obecnie funkcjonującego kształtu SAN.

Podobnie jak FCIP, iFCP wykorzystuje protokół TCP/IP do transportu danych do oraz z urządzeń pamięci masowych Fibrę Channel. Zwolennicy opisują iFCP jako połączenie tego, co najlepsze w świecie TCP, który dostarcza mechanizmy zapobiegania zatorom, wykrywania błędów oraz ich naprawiania, z tym, co najbardziej wartościowe w świecie SCSi, który daje solidny mechanizm „serializacji” poleceń i danych. Protokół iFCP umożliwia też łączenie istniejących magistrali SCSI i infrastruktury Fibrę Channel z internetem.

Protokół iFCP może całkowicie zastępować FCP, pozwalając na budowę infrastruktury FC przy użyciu Ethernetu. Częściej jednak proponowany jest jako uzupełnienie istniejącej struktury FC oraz jako alternatywa dla FCIP. Zwolennicy zwracają uwagę na to, że firmom, które już wdrożyły infrastruktury FC, wykorzystanie iFCP do łączenia „wysp FC SAN” pozwala uzyskać bardziej solidne rozwiązanie niż tunelowanie FCIP. Wykorzystując iFCP można ochronić integralność każdego przełącznika wyspy SAN i schemat stref rozwiązanie to jest też mniej podatne na ogólną awarię po ustanowieniu połączenia (przy założeniu, że bramy iFCP są zgodne) — patrz rysunek 4.3.

Obecnie iFCP przedstawia się jako narzędzie migracji dla firm, które docelowo zdecydowały się przenieść z infrastruktury FC na czysty iSCSI. Produkowane przełączniki zaczynają obsługiwać zarówno protokół iFCP, jak i iSCSI, a to znak, że gwiazda FCP powoli gaśnie.

Leave a reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>