Nowa hiperkonwergencja, stary storage

Wszyscy marzymy o dniu, w którym będziemy mogli zbudować nową infrastrukturę od podstaw bez żadnego istniejącego długu technicznego, który by nas ograniczał. Wdrożenie greenfield, gdzie wybieramy to, co najlepsze, uruchamiamy od zera i cieszymy się efektem. Jednak większość z nas żyje w realnym świecie, gdzie nie jest to zbyt realistyczne, i w rzeczywistości stajemy przed światem, w którym musimy planować na przyszłość, ale jednocześnie pracować z tym, co już mamy.

Radzenie sobie z tym, co mamy, jest niemal nieuchronnym faktem życia w IT i nie inaczej będzie, gdy podchodzimy do kwestii storage’u podczas przechodzenia z istniejącej architektury na hiperkonwergencję. W bardzo wielu przypadkach będziemy musieli zmierzyć się z sytuacją, w której istniejąca inwestycja w storage jest na miejscu i nie chcemy jej po prostu odrzucić, choć nie wpisuje się ona idealnie w naszą wizję hiperkonwergentnej przyszłości.

Istnieją oczywiście oczywiste opcje do rozważenia, takie jak zwrot dzierżawionego sprzętu, wycofanie starszego wyposażenia lub bezpośrednia sprzedaż nadal przydatnego sprzętu. Są to realne opcje i należy je rozważyć. Eliminacja starego sprzętu lub urządzeń, które nie pasują dobrze do bieżących planów, może być korzystna, gdyż możemy uprościć nasze sieci, zmniejszyć zużycie energii i możliwie odzyskać część naszych inwestycji.

W rzeczywistości jednak te opcje rzadko są opłacalne finansowo i musimy bardziej produktywnie wykorzystać nasze istniejące inwestycje technologiczne. Dostępne opcje zależą oczywiście od szeregu czynników. Przyjrzymy się jednak kilku przykładom, jak typowe urządzenia storage’owe mogą być przeznaczone do nowych celów w nowym systemie opartym na hiperkonwergencji, aby zachować ich użyteczność do czasu wycofania lub nawet, w niektórych przypadkach, bezterminowo.

Najprostszym sposobem ponownego wykorzystania istniejącego storage’u – dotyczy to w równej mierze zarówno NAS, jak i SAN – jest wyznaczenie ich jako celów kopii zapasowych lub archiwizacji. Tradycyjne urządzenia NAS i SAN są doskonałym sprzętem do backupu i generalnie mogą być używane przez niemal dowolny mechanizm backupu, niezależnie od podejścia lub dostawcy. A ponieważ są to generyczne cele backupu, jeśli stosowane są mieszane mechanizmy backupu – takie jak agentowe, bezagentowe i własne skrypty – wszystkie mogą działać na tym samym celu. Backup tak rzadko otrzymuje uwagę i inwestycję, na jaką zasługuje, że jest to nie tylko najprostsze, ale często najcenniejsze zastosowanie istniejącej infrastruktury storage’owej.

Oczywiście wszystko, co nadaje się do backupów, może być również używane do przechowywania archiwalnego. Potrzeby archiwizacyjne są generalnie mniej powszechne (tylko część firm potrzebuje storage’u archiwalnego, podczas gdy wszystkie potrzebują backupów) i mają niższy priorytet, więc jest to bardziej przypadek brzegowy ponownego użycia – niemniej wart rozważenia, szczególnie dla organizacji, które mogą pracować nad ponownym wykorzystaniem dużej liczby możliwie różnorodnych urządzeń storage’owych. Warto jednak zauważyć, że przejście na hiperkonwergencję ma tendencję do „spłaszczania” przestrzeni obliczeniowej i storage’owej w sposób, który może łatwo wprowadzić wartość do storage’u archiwalnego o niższej wydajności i priorytecie, która mogła nie istnieć lub nie była tak oczywista przed przebudową środowiska.

NAS ma wyjątkowe i korzystne zastosowania, takie jak bycie używanym jako ogólny sieciowy storage, szczególnie dla katalogów domowych użytkowników końcowych. Storage NAS może być używany w tak wielu miejscach w sieci, że jest bardzo łatwy w dalszym używaniu po zmianie głównych architektur. Najpopularniejszym przypadkiem jest przechowywanie danych własnych użytkowników z NAS podłączonym bezpośrednio do urządzeń użytkowników końcowych, co pozwala na odciążenie pojemności storage’owej, wydajności i ruchu sieciowego z infrastruktury konwergentnej na NAS. W rzeczywistości rzadko zdarza się usunięcie NAS-a z sieci hiperkonwergentnej, ponieważ jego potencjalna użyteczność jest tak wysoka i oczywista.

Zarówno SAN, jak i NAS mają potencjał do bezpośredniego podłączenia do maszyn wirtualnych działających na szczycie infrastruktury hiperkonwergentnej. W ten sposób mogą być nadal używane w tradycyjny sposób aż do czasu, gdy nie będą już potrzebne lub odpowiednie. Choć bezpośrednie podłączanie sieciowego storage’u do VM nie jest często zalecanym podejściem, istnieją przypadki użycia tego rozwiązania, które pozwala systemom zachowywać się tak samo jak zawsze w środowisku fizycznym. Jest to szczególnie przydatne dla mapowanych dysków i katalogów użytkowników przez NAS, podobnie jak wspomniałem w przypadku urządzeń użytkowników końcowych, ale przypadki z pewnością nie ograniczają się do tego.

SAN może zapewnić bardzo potrzebną funkcjonalność w niektórych przypadkach dla określonych obciążeń wymagających współdzielonego block storage, który w inny sposób nie jest dostępny lub eksponowany na platformie. Obciążenia na VM będą używać SAN-a tak jak zawsze i nawet nie będą świadome, że są zwirtualizowane lub konwergentne. Oczywiście możemy również podłączyć SAN do zwirtualizowanego serwera plików lub głowicy NAS działającej na naszej infrastrukturze hiperkonwergentnej, jeśli tiering dla tego rodzaju obciążenia zostanie uznany za odpowiedni.

Praca z istniejącą infrastrukturą podczas wdrażania nowej stanowi wyzwanie, któremu możemy jednak sprostać dzięki kreatywności i logicznemu podejściu. Storage jest niemal nieskończonym wyzwaniem, a posiadanie istniejącego storage’u do ponownego wykorzystania może z łatwością okazać się wyjątkowo korzystne.