Budowanie chmur obliczeniowych stało się możliwe dzięki rozwojowi wirtualizacji zasobów obliczeniowych. Większość rozwiązań chmurowych powstało jednak na bazie architektury zakładającej, że poszczególne węzły nie współdzielą między sobą zasobów (share-nothing), a infrastrukturę można skalować wszerz. Takie podejście nie spełnia wymagań wielu ważnych dla biznesu aplikacji. Kluczowe aplikacje z reguły operują na dużych zbiorach danych i wymagają sieci o dużych przepustowościach oraz małych opóźnieniach, a także różnych zaawansowanych mechanizmów. Podział takiej aplikacji na mniejsze części, które chmura będzie w stanie obsłużyć, jest problematyczne.

Jednakże skalowalność danych, wydajność i dostępność zmienia się w zależności od dostawcy chmury. Przykładowo, AWS i Azure oferują woluminy blokowe o pojemności aż do 1 TB. Azure zapewnia dostępność na poziomie 99,9 % dla pamięci masowych, co niestety jest poniżej poziomu wymagań nawet dla aplikacji typu tier 1. Z kolei woluminy AWS oferują wydajność na poziomie 4000 IOPS, co wystarczy do wielu zadań, ale również może okazać się zbyt mało już dla aplikacji tier 1. Dodatkowo, narzędzia administracyjne służące do zarządzania pamięciami masowymi w chmurze mogą różnić się od narzędzi używanych w lokalnych środowiskach, co stanowi przeszkodę w budowaniu środowisk hybrydowych.

Zobacz również:

• Cyfrowa transformacja z AI - co nowego na Google Cloud Next 24

Pamięci masowe w chmurze to często obiektowa pamięć masową, której zalety to bardzo duża skalowalność, prostota i niskie koszty. W wielu zastosowaniach, np. archiwizacji, jest to bardzo efektywne podejście, ale aplikacje tier 1 czy tier 2 z reguły wymagają regularnego dostępu i aktualizacji danych. Często od początku są optymalizowane pod kątem przechowywania danych w systemie plików lub na woluminach blokowych. Takie funkcje, jak replikacja w celu zapewnienia wysokiej dostępności czy migawki w celu klonowania danych jak również zarządzanie jakością usług to typowe cechy pamięci masowych działających w lokalnym środowisku. Są to również ważne aspekty, które należy rozważyć w momencie migracji aplikacji do infrastruktury chmurowej.

Wirtualizacja

Software Defined Storage (SDS) zakłada oddzielenie danych i warstwy zarządzania od warstwy fizycznej i przeniesienie tych elementów do warstwy fizycznej, która może działać na standardowych serwerach x86 – w lokalnym środowisku lub w chmurze. SDS umożliwia tworzenie środowiska SAN z wykorzystaniem dysków podłączonych lokalnie (DAS) do serwerów. Odpowiednie mechanizmy agregują wydajność i tworzą rozciągnięte między wieloma serwerami strefy dostępności, chroniące przed skutkami awarii. SDS może również posłużyć do budowy środowiska skalowalnego w szerz, w przeciwieństwie do woluminów blokowych, które cechują się ograniczeniami w zakresie pojemności i funkcjonalności.