Znajomość własnych aplikacji

Administratorzy pamięci masowych nie mogą sobie pozwolić na ignorowanie warstwy aplikacji. Bazy danych są aplikacjami stawiającymi pamięciom masowym bardzo wysokie wymagania, ale nie zawsze przyczyną problemów z bazami są problemy wydajnościowe macierzy. Warto zastanowić się czy tak naprawdę nie wynika on z problemów wewnątrz samej bazy danych i czy do ich rozwiązania nie wystarczy dodanie kilku indeksów. Indeksy przyspieszą obsługę często używanych zapytań a zarazem pozwolą znacznie zmniejszyć obciążenie pamięci masowej, dzięki czemu unikniemy kosztownych inwestycji w sprzęt.

Polecamy Thin provisioning - niewykorzystany potencjał?

Zobacz również:

• Plikowa, blokowa czy obiektowa pamięć masowa?
• Wyjaśniamy czym jest SD-WAN i jakie są zalety tego rozwiązania

Nie oznacza to bynajmniej, ze administratorzy storage’u muszą stać się specjalistami od baz danych czy ekspertami ds. innego rodzaju aplikacji. Jednak zanim podejmiemy decyzję o dokupieniu sprzętu, warto przynajmniej omówić go ze specjalistami od aplikacji, aby dowiedzieć się, w jaki sposób dana aplikacja korzysta z pamięci masowej.

Wybór najlepszych praktyk

Wśród wielu sposobów konfigurowania współpracy między hostami a pamięciami masowymi, zwykle jest tylko jedno dobre rozwiązanie. Niestety, tzw. najlepsze praktyki bardzo się różnią w zależności od tego, co chcemy osiągnąć. Problem komplikuje się jeszcze bardziej, gdy pamięci masowe są wdrażane w środowiskach wirtualnych, zwłaszcza w sytuacjach, gdy pamięć masowa obsługuje więcej niż jeden protokół i/lub, gdy pamięć masowa jest replikowana do odległej lokalizacji na wypadek awarii.

Na przykład, załóżmy, że platforma pamięci masowej obsługuje protokoły: NFS, iSCSI i Fibre Channel lub FCoE, i jest ona dołączana do hostów wirtualnych, które mogą również obsługiwać te same trzy protokoły. Którego użyć? Czy lepiej korzystać z różnych i dopasowywać je do różnorodnych obciążeń? Czy dla jednego rodzaju obciążeń lepiej zastosować udostępnianie na poziomie plików (NFS), a w przypadku innego udostępniać na poziomie bloków? Czy konfiguracja niektórych aplikacji do współpracy z pamięcią masową na poziomie bloków pozwoli na skorzystanie z oprogramowania do robienia kopii migawkowych (application-aware snapshotting) dostarczanego przez producenta pamięci masowej, podczas gdy protokół plikowy - już nie?

Polecamy Pamięci masowe: wiele protokołów - dobre i złe strony

Jeżeli dokonywana jest replikacja w odległej lokalizacji, to czy wybór pomiędzy blokowym bądź plikowym dostępem do pamięci masowej będzie miał wpływ na zdolność do pracy w trybie przełączania awaryjnego do zapasowego centrum danych (failover) lub przywracania normalnej pracy systemu w podstawowym datacenter (failback)? Czy istnieją jakieś ograniczenia w hiperwizorze, oprogramowaniu do replikacji, firmware pamięci masowej lub oprogramowaniu do automatycznego przełączania awaryjnego, które sprawią, że jeden protokół będzie lepszy od drugiego?

Wiedza i jeszcze raz wiedza

Poznanie właściwych odpowiedzi na te pytania oraz optymalne skonfigurowanie całości może wymagać sporo pracy i eksperymentów. Gorzej, gdy to się już zrobi, a kolejne uaktualnienie wersji każdego pojedynczego elementu nagle zupełnie zmieni dotychczasowe ustawienia lub po prostu coś popsuje. Dlatego też sięganie do dokładnej dokumentacji (a jeszcze lepiej po wiedzę ekspertów) - jest tak ważne.

Obecnie administrowanie storagem w nowoczesnym centrum danych wymaga dużych i różnorodnych umiejętności. Nie tylko trzeba wiedzieć, jak działa pamięć masowa wewnątrz i na zewnątrz, ale również jak integruje się z pozostałym sprzętem i oprogramowaniem. Dlatego dzisiejsi administratorzy odpowiedzialni za pamięci masowe muszą orientować się co i jak korzysta z zarządzanych przez nich zasobów.