A co z zarządzaniem?

Oprócz zapewnienia oszczędności kosztów, wynikającej z bardziej efektywnego wykorzystania sprzętu, sieci SAN miały również zmniejszyć koszty pracy dzięki lepszemu zarządzaniu. Zwolennicy sieci ENSA SAN wyobrażali sobie „inteligentną” i w dużej mierze „samozarządzalną” architekturę, której rozwój mógłby nadzorować stały personel. Obecne sieci SAN nie oferują takich możliwości.

Według zgodnych relacji, za pomocą obecnych narzędzi i technik jeden administrator może zarządzać najwyżej 300 – 500 gigabajtami pamięci masowej. Ilość ta znacznie się zwiększa, kiedy macierze są homogeniczne (co często podkreśla się w raportach pisanych na zamówienie producentów macierzy). Nie ma to jednak związku z topologią pamięci masowej. Większa liczba gigabajtów przypadających na administratora wynika z większej skuteczności oprogramowania do zarządzania pamięcią. Jeśli wszystkie wdrożone macierze pamięciowe pochodzą od jednego producenta, można zarządzać produktami jako całością za pomocą oprogramowania konfiguracyjno- administracyjnego dostarczonego przez tego samego producenta. Wzrost liczby gigabajtów przypadających na administratora nie ma nic wspólnego z sieciami SAN — jest pochodną homogenicznej infrastruktury.

Zarządzanie heterogenicznymi sieciami FC SAN pozostaje natomiast wciąż „prowizorką”. Powodem jest między innymi to, że w protokole Fibrę Channel brakuje usług wewnątrzpasmowego zarządzania.

Kiedy w firmie IBM zaprojektowano protokół Fibrę Channel, uważano go za niewiele więcej niż szeregowe łącze pamięci masowej, które miało zastąpić równoległą magistralę SCSI. Projektanci lubią powtarzać, że ich celem nie było opracowanie protokołu sieciowego, a tylko łącza szeregowego zatem funkcje „przypominające stos IP”, takie jak wewnątrzpasmowe zarządzanie i zabezpieczenia, zostały celowo wykluczone z protokołu. W roku 2000 stowarzyszenie Fibrę Channel Industry Association zamówiło raport przedstawiający plan rozwoju protokołu. Potwierdzał on istnienie tego deficytu i informował, że trwają prace nad dodaniem do protokołu usług, które sprawią, że w przyszłości będzie „bardziej sieciowy” .

W branży toczy się debata nad tym, czy Fibrę Channel jest protokołem sieciowym, czy nie. Howard Goldstein, sympatyczny człowiek i dobrze znany konsultant oraz szkoleniowiec, ma poglądy częściowo sprzeczne z przedstawionymi w tej książce. Z szacunku dla Howarda przytaczam tu jego argumentację w całości:

Wokół technologii Fibrę Channel urosło wiele mitów i rozbieżnych interpretacji. Jednym z tych mitów jest idea, że Fibrę Channel (FC) nie jest protokołem sieciowym. Wynika to między innymi z tego, że wiele usług FC realizowanych jest przez przełącznik FC, który w klasycznej implementacji OSI operuje w warstwie 2. (łącza danych). We współczesnych produktach wiele funkcji, które należały do warstwy 3. (sieci), 4. (transportu) i innych warstw, skonsolidowano w jednym urządzeniu.

Weźmy, na przykład, modem kablowy (lub DSL) zintegrowany z zaporą sieciową, serwerem DHCP, bramą, ruterem i przełącznikiem. Pełni on funkcje wszystkich siedmiu warstw architektury OSI, ale robi to w ramach cztero warstwowego modelu architektury internetowej.

Wspomniany pogląd bierze się również z błędnego założenia, że OSI jest modelem sieci idealnej i że wszystkie architektury sieciowe muszą klasyfikować funkcje w oparciu o ten model. Bardzo często prowadzi to do błędnego porównywania architektur i produktów związanych z sieciową pamięcią masową. Porównywać gigabitowy Ethernet z Fibrę Channel to tak jak porównywać ogryzek jabłka z całą pomarańczą.

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>