Wybór Storage Network
 
Ilość stosowanych technologii czy protokołów powiązanych z transportem danych pomiędzy serwerami, a różnego rodzaju pamięciami masowymi jest naprawdę spora. Wymieniając tylko kilka bardziej popularnych, staniemy przed wyborem pomiędzy m.in.: FC (FC-NVMe i SCSI-FCP), FCoE (FC-NVMe i SCSI-FCP), FCIP, iSCSI, iSER/RoCE, iSER/iWARP, NVMe-F/TCP, NVMe-oF/RoCE, NVMe-oF/iWARP, NFS, SMB, AFP, Amazon S3, OpenStack Swift, RBD (RADOS Block Device), DRBD Diskless, Ethernet lub Ethernet z obsługą DCB (CEE).

Ruch ten transportowany jest poprzez sieć SAN (Storage Area Network) do której budowy można wykorzystać wiele różnych technologii. Sieć SAN może być całkiem oddzielną siecią lub współdzielić jedną fizyczną infrastrukturę z siecią LAN (Local Area Network), co określane jest jako Unified Fabric.


Pomimo tak wielu technologii, pole wyboru dla Storage Network zwykle da się bardzo zawęzić.

iSCSI, iSER/iWARP, NVMe-F/TCP, NVMe-oF/iWARP, FCIP, NFS, SMB, AFP, Amazon S3, OpenStack Swift, RBD, DRBD Diskless może działać zarówno na bazie sieci Ethernet, jak i CEE (Converged Enhanced Ethernet). Przy czym dla iSCSI, iSER/iWARP i NVMe-oF/iWARP zalecamy CEE, które obsługuje DCB (Data Center Bridging).

iSER/RoCE, NVMe-oF/RoCE i FCoE wymaga CEE/DCB. Też tego wymagają różne rozszerzenia SMB i NFS, jak SMB-Direct czy NFS over RDMA. Dlatego jeżeli ktoś chce wykorzystywać technologię Ethernet w sieci SAN, to jednak zalecamy wybór przełączników z obsługą rozszerzeń CEE/DCB, jak Cisco Nexus.

Protokół FC (Fibre Channel) może działać na bazie technologii FC (Fibre Channel) lub na bazie technologii Ethernet. W tym pierwszym przypadku jest to klasyczne FC, które wymaga specjalnych przełączników FC, jak Cisco MDS. A w tym drugim jest to tak zwane FCoE (Fibre Channel over Ethernet), gdzie stosuje się przełączniki Cisco Nexus z obsługą rozszerzeń CEE/DCB. FCoE obsługiwane jest przez niektóre modele Cisco MDS.

W wielu przypadkach zastosowanie jednej sieci do transportu ruchu LAN i SAN będzie o wiele bardziej ekonomiczne pod względem zagospodarowania przestrzeni, obsługi, utrzymania i finansowym, niż budowanie niezależnej sieci SAN, składającej się z niezależnych przełączników, interfejsów oraz dodatkowego okablowania.

O ile kwestie zachowania ekonomii w obszarze zagospodarowania przestrzeni czy obsługi i utrzymania są raczej jasne i proste do wykazania, to kwestie ekonomii finansowej będą bardziej względne. Wynika to z tego, że pamięci masowe czy przełączniki z obsługą FCoE czy FCoE i FC będą zwykle droższe, od tych z obsługą samego FC. Nie zawsze, bo czasem z innych powodów musimy wybrać model danego urządzenia, który i tak obsługuje FCoE.

Z drugiej strony, jeżeli dostępne porty w ramach przełącznika Ethernet z obsługą FCoE/DCB mogą zaspokoić nasze potrzeby SAN i LAN, to zakup dodatkowego urządzenia zawsze będzie wiązał się nie tylko z kosztem samego zakupu, ale też z kosztem odnawiania gwarancji, aktualizacji, obsługi czy chłodzenia i zasilaniem takiego urządzenia.

Nie zawsze jest tak, że odnawiamy całą infrastrukturę. Dość często musimy się wpasować w coś co już istnieje i to już ogranicza wybór technologii. Dlatego też nie ma jednej i najlepszej technologii do wszystkiego, a bardzo często się je miesza. Decyzję tą trzeba dokładnie przekalkulować zarówno pod względem technicznym, jak i finansowym, gdyż dla każdej organizacji wynik tej kalkulacji może być całkiem inny, a mimo to dobry.

Technologia Ethernet rozwija się bardzo szybko. Umożliwia transmisję 100G, 200G jak i nawet 400G, podczas gdy w FC dla pojedynczego portu spotkamy się z 16G, 32G lub 64G. Warto też pamiętać, że 1G w Ethernet to więcej niż w 1G w FC. Wynika to z tego, że podawana w Ethernet prędkość, to prędkość niezależna od kodowania nadmiarowego, podczas gdy FC podaje prędkość, która uwzględnia kodowanie nadmiarowe, dokładające do danych dodatkowe bity.

Nie zawsze większa prędkość sieci ma kluczowe znaczenie i też nie zawsze jest odczuwalna w praktyce. Zależy to od tego, na jak długo budujemy naszą infrastrukturę oraz realnej prędkości nośników danych. Sama sieć to nie wszystko i trzeba też wziąć pod uwagę m.in. typy nośników (HDD/SSD), stosowane w nośnikach interfejsy (SATA/SAS/PCIe), zastosowaną konfigurację RAID czy wykorzystywane do komunikacji protokoły, jak SCSI, NVMe czy FICON.
 
Szybsza sieć z dużą szansą wystarczy na dłużej. Dlatego przy takich wyborach warto uwzględnić także inne plany, jak dla przykładu modernizacje pamięci masowych czy ich nośników.

Natomiast klasyczne FC ma również swoje mocne zalety do których w dużej mierze należy prostota implementacji, wystarczająca prędkość do obsługi tego co oferują dzisiejsze nośniki danych i naturalna separacja od tego co w sieci LAN, co przekłada się na większą stabilność i mniejszą awaryjność takiego środowiska.

Na pewno też nie musimy wybierać pomiędzy FC i FCoE. Dla przykładu możemy podłączyć IBM FlashSystem 9200 czy IBM FlashSystem 7200 z użyciem FC do przełączników Cisco MDS, które podłączymy z użyciem FC lub FCoE do przełączników Cisco Nexus, gdzie będą wpięte serwery z CNA (Converged Network Adapter).
 
CNA obsługuje FCoE (HBA) i Ethernet (NIC) na jednym porcie. Jest to jeden z częściej spotykanych scenariuszy, szczególnie tam gdzie działają serwery rackowe (ang. rack) Cisco UCS C lub kasetowe (ang. blade) Cisco UCS B. Choć w małych środowiskach można wszystko wpiąć do Cisco Fabric Interconnect lub Cisco Nexus.

Zatem FC może kooperować z FCoE w różnych obszarach sieci, a przełączniki Cisco MDS i Cisco Nexus potrafią przesyłać ruch FC pomiędzy portami z obsługą klasycznego FC i FCoE.

Dzięki CNA serwer można wyposażyć w jeden interfejs z dwoma szybkimi portami Ethernet. Redukuje to liczbę potrzebnych interfejsów oraz okablowania. W niektórych przypadkach, gdzie wymagane są dodatkowe karty w serwerach, umożliwia to wykorzystanie serwerów 1U, zamiast 2U.

Co do przełączników z obsługą DCB, jak Cisco Nexus, to o ile ich cena nie powinna bardzo różnić się od przełączników bez obsługi DCB (dużo zależy od konkretnych modeli), to na pewno będą to przełączniki z funkcjonalnościami ukierunkowanymi na pracę w centrach danych czy obsługę ruchu w środowiskach z serwerami i pamięciami masowymi. Stąd nie znajdziemy tam wielu zaawansowanych funkcjonalności, jakie stosowane są w sieciach kampusowych czy sieciach inteligentnych budynków, gdzie stosuje się Cisco Catalyst.

Dlatego najczęściej nasze centrum danych jest oddzielnym klockiem, który dołącza się do reszty infrastruktury sieci kampusowej, gdzie działają przełączniki Cisco Catalyst 9600/9500 lub urządzenia brzegowe Cisco Catalyst 8500.

 
Spotkać się można z nimi przy m.in. macierzach nowej generacji, jak i różnych rozwiązaniach SDS (Software Defined Storage). Niektóre z nich są specyficzne dla konkretnych rozwiązań, jak DRBD Diskless dla LINBIT SDS czy RBD dla Red Hat Ceph Storage, a też wiele z nich jest obsługiwanych przez różne rozwiązania pamięci masowych i SDS.

Poruszyliśmy tutaj tylko wybór Storage Network, podczas gdy warto też zastanowić się na wyborem konkretnych protokołów transportowych, gdzie pole wyboru jest znacznie większe. Zainteresowanych tymi obszarami odsyłamy do informacji o składowaniu danych oraz blokowych, plikowych i obiektowych przestrzeniach dla danych.
 
Stojących przed takimi wyborami This email address is being protected from spambots. You need JavaScript enabled to view it.. Istnieją pewne przesłanki czy wymagania, które sprawiają iż jedna technologia będzie w danym zastosowaniu lepsza od innej. W szczególności nieco inne wymagania dyktują dynamiczne środowiska chmur prywatnych, a inne środowiska z klasycznymi aplikacjami dla przedsiębiorstw. Zdarza się też często, że nie ma to aż tak dużego znaczenia i lepsze będzie zastosowanie czegoś bardziej uniwersalnego. Dlatego zamiast sprzeczać się nad wyższością jednej technologi nad drugą, warto przyjrzeć się obecnemu środowisku oraz temu co na koniec chcemy osiągnąć.

Zapraszamy do kontaktu drogą mailową This email address is being protected from spambots. You need JavaScript enabled to view it. lub telefonicznie +48 797 004 932.