Jakiś czas temu zgłębiałem wiedzę na temat przechowywania obiektów w ramach infrastruktury IT. Jak się okazało, tego typu rozwiązanie posiada nie tylko Amazon, ale też wiele innych producentów sprzętu i oprogramowania. Było to dla mnie sporym zaskoczeniem, że jest tego tak dużo. Dla nas, konsumentów takich usług, jest to dobre ze względu na możliwość wyboru. Ale…
Oprócz wspomnianego wcześniej Amazona, chyba każdy większy operator chmury posiada usługę, gdzie można przechowywać pliki. Sami też w naszym on-prem możemy uruchomić sobie taką usługę korzystając z takich producentów jak Dell, Quantum czy Cloudian. Każde z rozwiązań zapewne ma sporo plusów jak i minusów, ale…
Skoro mamy jakiekolwiek „ale” – postanowiłem sprawdzić oferowane rozwiązania.
Jak to zwykle bywa, nie można dogodzić każdemu. Znając problemy IT w Polsce, niemal zawsze sprowadza się to do problemów z funduszami, ale również do tego, że typowy Polak zrobi sobie to za darmo i będzie lepiej 😉(sic!). Oczywiście tak też można. Ale… po co sobie i innym utrudniać życie, Przyjrzałem się zatem bliżej komercyjnym rozwiązaniom, a wśród nich, temu co oferuje Cloudian.
Na pierwszy rzut oka Cloudian, to rozwiązanie jest super – skalowalne, bezpieczne itp., ale czy spotykamy się z tym na każdym kroku?
Każdy z producentów przekonuje nas, że jego rozwiązanie jest najlepsze i dzięki temu można również zaoszczędzić czas i pieniądze. Sprawdźmy, czy tak na pewno jest, czy nie jest to znów marketingowy bełkot.
Uruchomienie
Oczywiście, jak u każdego producenta mamy możliwość wyboru między dostarczonym gotowym rozwiązaniem, a samym oprogramowaniem, które możemy uruchomić w ramach własnego sprzętu lub środowiska wirtualnego. W przypadku gotowego rozwiązania, Cloudian oferuje kilka konfiguracji sprzętowych – od mniejszej (120TB do 168TB per pojedynczy serwer), do dużych, gdzie możemy zmieścić 1536TB. Dla bardziej wymagających jest też opcja oparta o dyski NVMe.
W przypadku wybrania wersji bez serwerów, możemy uruchomić oprogramowanie na dowolnym niemalże sprzęcie.
Należy oczywiście pamiętać o minimalnych wymaganiach jakie musimy spełnić, aby osiągnąć odpowiednią wydajność i skalowalność całej platformy. Cloudiana możemy uruchamiać w różnych chmurach, rozciągać go między kilka data center, jak również możemy zrobić hybrydę. Cały system wspiera możliwość uruchomienia load balancera.
Możemy również wykorzystać pojedynczy DNS, aby „rozłożyć” ruch na poszczególne serwery w klastrze, ale okazuje się, że w produkcyjnych środowiskach jest to niezalecane. Trochę szkoda, ponieważ musimy wykorzystać dodatkowe oprogramowanie i sprzęt, które trzeba wcześniej skonfigurować i utrzymywać, aby wszystko działało poprawnie. Na szczęście możemy wykorzystać HAproxy lub inne podobne oprogramowanie czy sprzęt.
Nie będę obrazował jak to działa, ponieważ zasada jest banalnie prosta – analogiczna jak w przypadku innych usług, które korzystają z load balancerów.
Funkcjonalności
Było kilka słów na temat uruchomienia, to teraz wspomnę o samej funkcjonalności. Poza standardowymi elementami jak kompatybilność z S3, mamy też Multi-Tenant Service pomocny przy integracji rozwiązania z chmurami opartymi np. o VMware Cloud Directora. Ale o tym jeszcze będzie za chwilę.
Oczywiście jest: QoS, monitorowanie, raportowanie, auto-tiering, kompresja czy zasady bilingu, które również ładnie komponują się w rozwiązanie… Ach tak, jeszcze kontenery!
Jakżebym mógł zapomnieć o możliwości integracji Cloudiana z Kubernetesem 😉 Gdy mówimy o funkcjach zabezpieczania danych możemy wykonywać repliki lub Erasure Coding. Wybór metody zależy od wielu czynników. Zaczynając od miejsca jakie przeznaczymy na przechowywanie danych, na szybkości odczytu, kończąc.
W przypadku replikacji obiekt jest zapisywany wielokrotnie w całości, np. obiekt o wielkości 100MB będzie posiadał w łącznie 3 repliki, więc sumarycznie zostanie wykorzystane 300MB. Erasure Coding dzieli obiekty danych na fragmenty i dodaje dane parzystości w celu ochrony danych. Zazwyczaj wymaga to od 20 do 50% więcej miejsca. Niestety, metoda Erasure Coding konsumuje więcej mocy obliczeniowej. Dodatkowo przy rozproszeniu danych między różnymi DC, w różnych lokalizacjach geograficznych przy niskich przepustowościach, odczyt danych może być koszmarnie wolny.
Oto przykład
Mając nakreślone funkcje i możliwości oprogramowania możemy pokazać to na przykładzie. Będę bazował na VMware Cloud Directorze i jego komponentach w kontekście integracji rozwiązania HyperStore w celu udostępniana zasobów na potrzeby przechowywania obiektów. Zobaczmy schemat poniżej. Widzimy, że mamy 5 nodów HyperStore, load balancer i VMware Cloud Directora.
Sprawa jest trywialna. Użytkownik może wykorzystać vOSE aby połączyć się do zasobów lub też może to zrobić z poziomu VMware Cloud Directora. W takiej sytuacji dla użytkownika część od load balancera w „dół” nie istnieje, ponieważ nie jest świadomy w jaki sposób jest realizowany backend usługi. Oczywiście zamiast HyperStore można wykorzystać ECS lub samego Amazona. W przypadku, gdy nie jesteśmy cloud providerem nasza architektura zaczyna się od load balancera i kończy na klastrze serwerów przechowujących dane. Proste, prawda? Oczywiście, że nie! 😉, ale…
Bardziej szczegółowo o wymaganiach sieciowych, load balancerów i innych aspektach samego uruchomienia napiszę w kolejnym artykule.
Wtedy okaże się czy Cloudian jest naszym rycerzem na białym koniu, czy to może zwykły paź na kobyle, która nie nadaje się do niczego.
C.D.N.
„Artykuł został opublikowany na łamach bloga evoila Poland.”
