Protokół iSCSI

Tak oto, jeżeli protokół iSCSI jest przeznaczony dla małych lub średnich środowisk IT, które nie mają wielkich silosów taśm, to czy kopie zapasowe wciąż będą siłą napędową lub „zabójczą aplikacją” jego wdrażania? Dopóki nie znajdzie się zastosowanie iSCSI, które sprawi, że w mniejszych środowiska IT zrezygnuje się z pamięci podłączonej do serwera oraz sieciowej pamięci masowej (ang. network-attached storage, NAS), wydaje się, że producenci będą tracić czas na „zabawę” z iSCSI.

Inne pytania odnośnie iSCSI dotyczą podstawowych korzyści, które mają wynikać ze stosowania tego protokołu w szczególności odnosi się to do twierdzenia, że zapewnia on łatwiejszy w obsłudze i bardziej bezpieczny fundament do budowy SAN. Chociaż iSCSI umożliwia wykorzystanie protokołów SNMP i IPSec (standardów w pakiecie TCP/IP) do administrowania wewnątrzpasmowego i zapewnienia bezpieczeństwa pamięci masowych, otwartym pytaniem pozostaje, czy ktokolwiek obecnie używa tych protokołów.

W trakcie prezentacji, która miała niegdyś miejsce w Bostonie, pewien menedżer pamięci masowej zapytał: „Gdybyśmy chcieli używać SNMP i IPSec, to czy nie wykorzystalibyśmy ich w zewnątrzpasmowej sieci IP, której już używamy do zarządzania serwerami i urządzeniami pamięci masowych w infrastrukturze FC?” Dobrze powiedziane. W prasie branżowej ukazało się ostatnio dużo artykułów o niechęci organizacji do implementacji zarówno IPSec (ponieważ protokoły te nakładają kilka znaczących i pracochłonnych wymagań administracyjnych), jak i SNMP (z powodu właściwych mu problemów z bezpieczeństwem). Jeżeli protokoły te nie są powszechnie użytkowane w zabezpieczaniu lub zarządzaniu sieciami lokalnymi opartymi na IP, to dlaczego ktoś przekonuje, że mogą coś wnieść do IP SAN?

Ponadto, pomimo zapewnień dostawców, że sieci iSCSI SAN są mniej zagadkowe niż infrastruktura FC — to jest, że protokół IP jest bardziej znany niż protokół Fibrę Channel — niejeden menedżer ds. pamięci masowej kwestionował to twierdzenie. Uczestnik niedawnej konferencji branżowej zastanawiał się głośno: „Czy administratorzy pamięci masowej nie musieliby się uczyć systemu operacyjnego IOS przełączników Cisco i czy rzeczywiście byłoby to łatwiejsze niż nauka osobliwości protokołu Fibrę Channel?”

Następnym ważnym — przede wszystkim z praktycznego punktu widzenia — pytaniem jest to, jak dostawcy przekonają swoich partnerów, sprzedawców i integratorów do sprzedaży rozwiązań iSCSI, zwłaszcza jeśli alternatywy FC przyniosą wyższą marżę zysku. Choć chciałoby się wierzyć, że dystrybutorzy i integratorzy będą z wrodzonej szlachetności oferować rozwiązania, które spełniają wymagania klientów, zamiast takich, które jedynie napychają kieszenie sprzedawców, mnogość niedopracowanych rozwiązań opartych na kiepskich technologiach wskazuje, że jest inaczej. Ostatecznie, to sprzedawcy i integratorzy zdecydują, jaką technologię przedstawią klientom. Organizacje sprzedaży kanałowej (jak czasami nazywa się takie grupy) od dawna były identyfikowane jako prekursorzy technologii, szczególnie w sprzedaży kompleksowej, która wymaga wielu osobistych spotkań z klientami.

2 comments to Protokół iSCSI

  • Vader  says:

    U nas w firmie na przykład, protokół ISCSI się w ogóle nie spradził. Mimo dosyc niewielkiej sieci oraz zoptymalizowanego połaczenia, dane „gubly” sie po drodze i nie mozna ich bylo poprawnie odebrac.

  • Zgred  says:

    „jak dostawcy przekonają swoich partnerów, sprzedawców i integratorów do sprzedaży rozwiązań iSCSI, zwłaszcza jeśli alternatywy FC przyniosą wyższą marżę zysku”

    Jak? Nie przekonają. Po prostu. To rozwązanie jest zbyt drogie a zarazem zbyt tanie aby moglo zostac wprowadzone na masową skalę.

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>