SDS pełen wyzwań

Idea pamięci masowych realizowanych programowo SDS (Software Defined Storage) może przynieść wiele korzyści, m.in. uprościć architekturę czy ułatwić skalowanie, ale trzeba też liczyć się z poważnymi wyzwaniami podczas wdrożenia i użytkowania.

Na temat SDS dużo się mówi i pisze. Ponieważ sprzęt przestaje być wyróżnikiem, producenci coraz chętnie markują swoje produkty jako zdefiniowane programowo. Jak z każdą nową technologią, pewne pojęcia wymagają tutaj uporządkowania. Choćby podstawowa definicja SDS jest różnie formułowana. Najczęściej pod terminem SDS rozumie się taką architekturę, w której oprogramowanie przejmuje funkcje pamięci masowych dotychczas realizowane sprzętowo. Ta definicja jest na tyle szeroka, że obejmuje szerokie spektrum różnych implementacji. Nieco węższa definicja mówi, że SDS oznacza realizowanie funkcji pamięci masowych na tych samych maszynach, na których działa oprogramowanie serwerowe i aplikacje.

SDS może przynieść korzyści nie tylko w ogromnych centrach danych, jakimi operują Google i Amazon, ale również w małych środowiskach, np. w zdalnych lokalizacjach (oddziałach), gdzie trzeba poruszać się w ramach mocno ograniczonego budżetu. Skorzystają również małe i średnie firmy, które często mają podobne ograniczenie, a dodatkowo szukają rozwiązań, które są proste do wdrożenia.

Wyzwania

Obok szeregu korzyści SDS przynosi też wyzwania, z których najistotniejsze to aplikacje oraz dostępność danych. W tradycyjnych pamięciach masowych wysoką dostępność osiąga się poprzez zastosowanie nadmiarowych kontrolerów. W razie awarii jednego z kontrolerów drugi przejmuje jego zadania. W przypadku SDS trzeba tworzyć trzy kopie danych (triple mirroring), aby osiągnąć taki sam poziom dostępności. To oznacza znaczny narzut jeśli chodzi o wykorzystanie przestrzeni dyskowej i prowadzi do zmniejszenia szybkości reagowania systemu na żądania aplikacji. Korzyści, jakie wiążą się ze skalowalnością i mobilnością SDS będą mniejsze w przypadku różnej lokalizacji danych - jeśli aplikacja próbuje uzyskać dostęp do danych, które nie zostały zapisane w lokalnym węźle, następuje spadek wydajności.

Oprogramowanie SDS musi być tak skonfigurowane, aby współpracować z różnymi urządzeniami. To wymaga od działu IT weryfikowania indywidualnie w każdym przypadku kwestii kompatybilności, wsparcia różnych macierzy oraz konieczność pogodzenia się z ewentualnymi ograniczeniami, w przypadku braku pełnej kompatybilności. Oprócz zmagania się z zarządzaniem macierzami różnych producentów, dochodzi jeszcze kwestia zarządzania oprogramowaniem SDS. To dodatkowe zadanie dla działu może okazać się sporym wyzwaniem. Szczególnie, jeśli weźmie się pod uwagę, że SDS może obejmować nie tylko sieciowe pamięci masowe (NAS i SAN), ale także dyski podłączone bezpośrednio do serwerów (DAS). Jakiekolwiek próby skryptowego zarządzania ścieżkami danych łączącymi te urządzenia może spowodować powstanie wąskich gardeł. Zastrzeżone interfejsy API do wielu systemów pamięci masowych nie ułatwią integracji czy ograniczą możliwość wykorzystania właściwości sprzętu.

Jeśli do już złożonego środowiska pamięci masowych dodamy jeszcze nośniki DAS, spowoduje do wydłużenie procesów przydzielania zasobów. To prowadzi do obciążania pracowników nadmiernymi zadaniami, a cały proces czyni podatnym na ludzie błędy.

Wprowadzenie nowego typu pamięci masowych sprawia również, że widok przestrzeni dyskowej staje się jeszcze bardziej poszatkowany. Połączenie lokalnych zasobów dyskowych (DAS) z sieciowymi pamięciami masowymi w centrum danych może doprowadzić do lepszego wykorzystania wszystkich dostępnych zasobów dyskowych, ale jednocześnie jest wyzwaniem, jak scentralizować monitorowanie takiego środowiska.

Dlatego przed podjęciem decyzji o wdrożeniu SDS trzeba rozważyć szereg czynników, w szczególności wymagania dotyczące wydajności, dostępności oraz skalowalności. Jest bardzo prawdopodobne, że w nowoczesnych centrach danych systemy SDS będą funkcjonować równolegle ze specjalizowanymi systemami pamięci masowych.

Recepta na sukces

Mimo ewidentnych korzyści SDS to również wyzwania, z których część występuje także w świecie tradycyjnych pamięci masowych. Administratorzy potrzebują jednej konsoli administracyjnej, scentralizowanego monitorowania, otwartych API zaprojektowanych w modelu REST oraz prostszych procesów przydzielania zasobów (warto porównać czas potrzebny na przygotowanie przestrzeni dyskowej z czasem uruchomienia nowej maszyny wirtualnej). Podstawowe funkcje, jak uwierzytelnianie, powinny być częścią systemu, aby dział IT mógł się skupić na usługach bezpośrednio związanych z pamięciami masowymi. Ułatwieniem jest też integracja SDS z platformą do wirtualizacji serwerów, ale warto, aby oprogramowanie SDS nie było przystosowane do pracy tylko z jedną platformą. W centrach danych coraz częściej bowiem w użyciu jest więcej niż jedno rozwiązanie do wirtualizacji serwerów.

Jest jeszcze za wcześnie, aby wskazać, którzy z producentów SDS zmierzają w najlepszym kierunku. Niektórzy zwolennicy SDS sugerują, że optymalnym podejściem jest wykorzystanie standardowych dysków podłączanych bezpośrednio do urządzeń końcowych, zamiast wykorzystywania macierzy dyskowych. Pojawiają się nawet sugestie, że można zaoszczędzić, pozbywając się przestarzałych macierzy i całkowicie przejść na zwykłe dyski. Bardziej realistyczne jest jednak założenie, że SDS prowadzi do lepszego wykorzystania inwestycji poczynionych w pamięci masowe. Umożliwia bowiem skalowanie oraz efektywne kontrolowanie i zarządzanie pamięci masowymi, począwszy od korporacyjnych macierzy na dyskach DAS skończywszy, używanymi w zależności od bieżących potrzeb użytkowników i aplikacji.

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200