Rozwiązania konwergentne i hiperkonwergentne. Które lepsze?

Transkrypt

1 TomaszJangas.com Rozwiązania konwergentne i hiperkonwergentne. Które lepsze? 5 listopada 2017 Czy to przypadkiem nie jest dyskusja z kategorii tych o wyższości Świąt Bożego Narodzenia nad Świętami Wielkanocnymi? Różnice pomiędzy obydwoma typami rozwiązań są dość znaczące. Na koniec dnia w obydwu przypadkach jesteśmy w stanie osiągnąć podobne rezultaty (dostarczyć infrastrukturę typu IaaS, PaaS lub SaaS) i możemy zaspokoić często bardzo podobne wymagania biznesowe. Dochodzimy do nich jednak nieco innymi drogami. Po co nam w takim razie ten wybór? Okazuje się, że nie jest do końca obojętne, które z tych rozwiązań wybierzemy. Dzisiaj dla jednej aplikacji lepszym rozwiązaniem będzie środowisko konwergentne, podczas gdy dla innej hiperkonwergentne. Podkreślam dzisiaj, ponieważ, patrząc na rozwój aplikacji, jutro może to wyglądać zupełnie inaczej. Ale zacznijmy od początku Tomasz Jangas

2 Przede wszystkim inna architektura. To jest jedna z podstawowych różnic pomiędzy tymi rozwiązaniami. Architektura implikuje z kolei sposób skalowania tych rozwiązań i stąd możesz często również natrafić na takie określenia jak rozwiązania typu scale-out (hiperkonwergentne) i rozwiązania typu scale-up (konwergentne). Rozwiązania konwergentne zbudowane są w tradycyjny sposób z takich komponentów jak: serwer (klaster serwerów), sieć SAN, sieć LAN, macierz dyskowa. Każdy z tych komponentów może być w takiej architekturze skalowany niezależnie, w odpowiedzi na konkretne zapotrzebowanie. Na przykład brakuje przestrzeni dyskowej w macierzy, rozbudowujemy samą macierz. Brakuje mocy obliczeniowej w klastrze serwerów, dodajemy kolejne węzły do klastra lub kolejne procesory do serwera, bez konieczności dodawania dysków, które mamy zainstalowane w macierzy. Takiej elastyczności nie będziemy mieli w rozwiązaniach typu scale-out, gdzie wszystkie zasoby dodajemy jednocześnie (niezależnie od tego czy ich potrzebujemy, czy nie) wewnątrz kolejnego modułu, serwera, węzła w klastrze. Dygresja #1: W literaturze oraz w różnych artykułach pojawiają się również takie określenia, jak: Hyperscale Server SAN Storage - storage DAS, rozproszony i zainstalowany wewnątrz wielu serwerów, pracujących jako węzły jednego organizmu (klastra) Enterprise Server SAN Storage - kombinacja rozwiązań z tradycyjnymi macierzami, macierzami flash i pamięciami flash PCIe, instalowanymi wewnątrz serwerów Tomasz Jangas

3 Traditional Enterprise Storage (SAN, NAS, DAS) tradycyjne macierze dyskowe SAN, NAS i DAS; przewiduje się, że to właśnie ten obszar rynku będzie brutalnie pożerany przez dwie poprzednie technologie Konwergentne. Brzmi znajomo? Jaka jest różnica pomiędzy gotowym rozwiązaniem konwergentnym, a tradycyjną infrastrukturą serwer-sieć-pamięć masowa. W końcu przecież sam mogę zbudować takie środowisko w oparciu o jego poszczególne elementy (serwery, SAN, LAN, pamięć masowa), kupione na przykład od różnych dostawców. Mam wtedy na pewno zdecydowanie większy wpływ na to jak ono będzie wyglądać. W przypadku rozwiązania konwergentnego dostajemy gotowy appliance, zbudowany przez jednego producenta. A ponadto: 1. Do zarządzania appliancem wykorzystywane jest jedno oprogramowanie orkiestrujące. Nie muszę wykonywać konfiguracji oraz codziennych zadań administracyjnych w wielu oddzielnych aplikacjach, z których każda zarządza swoją warstwą (serwery, SAN, pamięć masowa). W oparciu o to oprogramowanie orkiestrujące łatwiejsze będzie zautomatyzowanie procesów dostarczania usług dla biznesu. To pierwsza przewaga nad tradycyjną infrastrukturą, budowaną niezależnie z oddzielnych komponentów. 2. Aktualizacja wersji mikrokodów realizowana jest dla całego rozwiązania (z gwarancją, że nowe wersje zostały już wcześniej przetestowane na całej ścieżce IO), co zdecydowanie upraszcza proces zarządzania zmianami w takiej infrastrukturze. To druga przewaga nad tradycyjnym podejściem. 3. Dostarczone rozwiązanie jest od razu gotowe do pracy. Nie muszę go konfigurować i testować kompatybilności jego komponentów przed uruchomieniem na produkcji. To z kolei oznacza szybszy czas dostarczenia usług dla biznesu. Trzecia przewaga nad tradycyjnym podejściem. Takich korzyści można wymienić znaczne więcej, ale ponieważ to nie o tym chciałem Wam opowiedzieć w tym artykule, dlatego ograniczę się tylko do tych trzech powyższych. Dygresja #2: Gartner podzielił rynek rozwiązań konwergentnych i hiperkonwergentnych na trzy grupy: ISS (Integrated Stack Systems) zintegrowane rozwiązania (serwery, storage, sieć), przeznaczone dla konkretnej aplikacji, na przykład: Oracle Exadata, IBM PureApplication, Teradata Tomasz Jangas

4 ISS (Integrated Infrastructure Systems) zintegrowane rozwiązania (serwer, storage, sieć) wykorzystywane do budowy prywatnej chmury, na przykład: VCE Vblock, HP ConvergedSystem, IBM PureFlex, NetApp FlexPod, Hitachi UCP CI/RS FBC (Fabric-based Computing) zintegrowane, modułowe rozwiązania (serwer, storage, sieć) wykorzystywane do budowy prywatnej chmury, na przykład: SimpliVity, Nutanix, HP Moonshot, Huawei FusionCube, Hitachi UCP HC Hiperkonwergentne. Trendy, jazzy, fruity? Rozwiązania tego typu zbudowane są ze zintegrowanych ze sobą modułów - serwerów, pracujących jak jeden organizm (dla uproszczenia nazwijmy go klastrem). Wewnątrz tych serwerów zainstalowane są wszystkie zasoby tego klastra. A kontrolę nad klastrem utrzymuje oprogramowanie (SAN Software), które spina ze sobą serwery na poziomie sieciowym. Ponieważ musimy zapewnić odpowiednią jakość komunikacji pomiędzy węzłami klastra, dlatego najczęściej wykorzystywanym do tego celu medium transmisyjnym jest albo InfiniBand, albo Ethernet gwarantujący krótkie czasy opóźnień. Kluczową rolę w przypadku rozwiązań hiperkonwergentnych odgrywa oprogramowanie, które kontroluje działanie całego rozwiązania. Jest ono odpowiedzialne również za utrzymanie spójności danych oraz posiada wbudowane mechanizmy, których celem jest zapewnienie niezawodności i ciągłości działania. A ponieważ te oraz wiele innych podstawowych funkcji przeniesionych zostało tutaj z warstwy sprzętowej do warstwy programowej, dlatego: (1) rozwiązaniami hiperkonwergentymi łatwiej się zarządza oraz (2) prostsza jest w ich przypadku droga do pełnej automatyzacji procesów Tomasz Jangas

5 Warstwa definiowana programowo. Jest to kluczowy element w architekturze rozwiązania hiperkonwergentnego. Jej głównym celem jest dostarczenie dla systemu operacyjnego pewnej warstwy abstrakcji (wirtualizacji), która pozwoli na korzystanie z określonych zasobów rozwiązania, w taki sposób, aby przykryć ich rozproszenie pomiędzy różnymi modułami serwerami rozwiązania. Znakomitymi przykładami takich warstw są: 1. Software Defined Storage (SDS) łączy dyski z wszystkich serwerów wchodzących w skład klastra i przedstawia je w postaci jednego wspólnego zasobu dyskowego: o VMware vsan o Microsoft Storage Spaces o Red Hat ovirt-glusterfs o Citrix Sanbolic 2. Software Defined Networking (SDN) przenosi procesy zarządzania przełącznikami z poziomu fizycznych portów do oprogramowania, które śledzi obciążenia w maszynach wirtualnych: o VMware NSX o Microsoft Hyper-V Network Virtualization (HNV) o Cisco Extensible Network Controller (XNC) Warstwa definiowana programowo może być dostarczona w oparciu o rozwiązania znanych i popularnych producentów środowisk wirtualnych. Tutaj funkcja pamięci masowej jest zazwyczaj wbudowana w hypervisor (w jądro systemu) i dostarczana w natywny sposób bezpośrednio do wirtualnych maszyn. W przypadku rozwiązań typu open source do zarządzania funkcją pamięci masowej wykorzystywany jest najczęściej rozproszony system plików. Które z tych rozwiązań będzie optymalne dla moich aplikacji? Moim zdaniem właśnie od odpowiedzi na to pytanie powinniśmy zacząć całą dyskusję. Rozwiązania hiperkonwergentne będą się znakomicie sprawdzać dla nowoczesnych aplikacji, które przede wszystkim potrafią skorzystać z dobrodziejstw architektury scale-out. Niektóre przykłady takich aplikacji, to: o o o równoległe bazy danych (Casandra, Hive, Impala, MongoDB, SAP Hana), środowiska do analityki danych (Hadoop, MapR, Cloudera, Hortonworks, Pentaho, Spark), aplikacje pracujące w kontenerach (Docker, Rocket), Tomasz Jangas

6 o nowoczesne aplikacje webowe. Takie aplikacje potrafią skalować się w kierunku horyzontalnym (scale-out), poprzez dodawanie zasobów w postaci kolejnych węzłów w klastrze, kolejnych wirtualnych maszyn lub kolejnych kontenerów. Rozwiązania konwergentne będą się z kolei lepiej sprawdzać w przypadku tradycyjnych aplikacji, które wymagają dużych ilości zasobów dla pojedynczej instancji systemu operacyjnego i które skalują się wertykalnie poprzez dodawanie zasobów wewnątrz serwera lub wirtualnej maszyny. W tej grupie aplikacji można wymienić na przykład bazy danych, takie jak Oracle DB, DB2, Sybase, MS SQL. Moim zdaniem, należy się spodziewać, że wraz z rozwojem rozwiązań hiperkowergentnych aplikacje tego typu będą stopniowo przepisywane od nowa w taki sposób, aby również i one potrafiły wykorzystać zalety nowoczesnej architektury skalowanej horyzontalnie (scale-out). Już w tej chwili możemy zaobserwować trend polegający na zastępowaniu tradycyjnych typów obciążeń, które z reguły uruchamiane są wewnątrz jednej wirtualnej maszyny lub w jednym kontenerze obciążeniami, które znakomicie sobie radzą pracując równocześnie na wielu wirtualnych maszynach/ kontenerach. Quo vadis? Elastyczne architektury scale-out, skalowalne liniowo, łatwe w rozbudowie, w pełni zautomatyzowane i rozliczane w modelu subskrypcyjnym ( płać tylko za to, czego używasz ). Idealne dla rozproszonych obiektowych magazynów danych, rozproszonych systemów plików, równoległych baz danych oraz aplikacji pracujących równolegle w wielu wirtualnych maszynach lub kontenerach (na przykład działających w oparciu o mikroserwisy). Rozwiązania zbudowane w oparciu o inteligentną warstwę programową (typu software defined) oraz pod spodem zwirtualizowany sprzęt commodity klasy x86. Młode firmy często budują swoje aplikacje i środowiska właśnie w oparciu o takie podejście. Oczywiście im jest łatwiej zacząć od razu już na tym poziomie technologicznym. Poza tym duża ich część korzysta z usług dostawców chmur publicznych, którzy już teraz swoją ofertę mają przystosowaną do uruchamiania tego typu aplikacji. Również w wielu istniejących przedsiębiorstwach, szczególnie tych większych, które charakteryzują się dużą bezwładnością i muszą utrzymywać stare aplikacje, już teraz można spotkać zarówno jeden jak i drugi rodzaj środowisk. Dzisiaj często wygląda to w ten sposób, że te kluczowe aplikacje i krytyczne z punktu widzenia prowadzenia biznesu, są często aplikacjami, działającymi w infrastrukturach typu scale-up (konwergentnych). Z kolei nowe projekty na przykład w zakresie wirtualnych desktopów, analityki danych Tomasz Jangas

7 niestrukturalnych, czy nowych hurtowni danych, uruchamiane są w środowiskach, charakteryzujących się architekturą typu scale-out (hiperkonwergentną). Masz inne zdanie na ten temat? Chciałbyś uzupełnić powyższy punkt widzenia? Zapraszam do dyskusji Tomasz Jangas