Pamięć flash Pionierska firma Pure Storage ogłosiła niedawno, iż zmodernizuje swoją platformę sterowania Fusion, aby udostępnić pojemność pamięci masowej w swoich macierzach za pośrednictwem klas pamięci masowej, które umożliwiają łatwe przydzielanie jej dowolnej aplikacji, która tego potrzebuje.
Potencjalnie niesie to ze sobą wiele korzyści, gdyż sprawia, iż przechowywanie danych staje się prostsze i bardziej dostępne dla wielu aplikacji na wielu hostach i w zróżnicowanych środowiskach.
Kubernetes od dawna korzysta z koncepcji klas pamięci masowej w celu zapewnienia trwałe przechowywanie z zdefiniowanymi profilami do aplikacji. Ale to w środowiskach kontenerowych, które Kubernetes kontroluje od góry do dołu.
W jaki więc sposób klasy pamięci masowej będą działać w przypadku płaszczyzny sterowania Fusion firmy Pure w heterogenicznych środowiskach centrów danych?
Podczas wydarzenia Pure Accelerate w Las Vegas w połowie czerwca spotkaliśmy się z Czyste przechowywanie założyciel i główny wizjoner John „Coz” Colgrove żeby go zapytać.
Jak podsumowałbyś nową funkcjonalność ogłoszoną dla Fusion?
John „Coz” ColgroveCelem Fusion jest umożliwienie zarządzania flotą macierzy w formie usługi, co pozwala na zdefiniowanie niewielkiej liczby klas pamięci masowej i uzyskanie w ten sposób większej spójności środowiska.
Typowy klient kupuje kilka tablic. W następnym roku kupuje więcej tablic, a potem więcej w kolejnym roku. Może w następnym roku wycofuje kilka z wcześniejszych i kupuje więcej.
Mają tę flotę, którą kupili w wielu różnych momentach. Mają różne klasy tablic, może różne generacje tej samej klasy. Mają więc tę flotę, która jest heterogeniczna i mają problem z zarządzaniem nią, aby uzyskać jednolite wykorzystanie.
Ponieważ oczywiście poziomy wydajności i pojemności tych rzeczy są różne. Ta ma trzy cechy, których ta druga nie ma. Ta ma dwie różne cechy. I tak masz ten bałagan 27 różnych typów pamięci masowej w swoim centrum danych.
Teraz próbujesz dokonać zmiany. Na przykład, jeżeli chcę wdrożyć tę nową funkcję bezpieczeństwa, zaplanowanie jej i wykonanie jest o wiele trudniejsze, ponieważ wszystkie te różne typy pamięci masowej oznaczają, iż musisz wymyślić, jak ją zastosować.
Fusion powinno pozwolić Ci na posiadanie niewielkiej liczby osób, które definiują klasy pamięci masowej z atrybutami. Następnie możesz sprawić, aby Twoi użytkownicy zrobili to za pośrednictwem Dostarczanie APIlub przez cały czas możesz zlecić to administratorom IT, poprzez otwarcie przez użytkownika zgłoszenia z informacją „Potrzebuję 10 TB” i oni sami to rozwiążą.
Zamiast przeglądać wszystkie te macierze i zastanawiać się, która ma odpowiednią pojemność, która ma wystarczającą wydajność, która ma odpowiednie dostrojenie, Fusion dokona tego wszystkiego i je sklasyfikuje, w następujący sposób: oto moja pamięć masowa klasy A, oto moja pamięć masowa klasy B, a oto moja pamięć masowa klasy C.
I powiedziałbym każdej organizacji, iż naprawdę nie powinniście mieć więcej niż trzy lub może cztery klasy. W ten sposób możecie wnioskować i przenosić swoje usługi centrum danych w sposób spójny. Wszystko to powinno następnie pozwolić ludziom uzyskać znacznie większe wykorzystanie swojego środowiska.
Ponieważ masz inny problem, ponieważ kupujesz te tablice, a na przykład dział finansowy posiada tablicę i ma na niej swoje aplikacje. A jeżeli jej nie wypełnią, nie chcą, żeby ktokolwiek inny na niej był, prawda? Musisz się tego pozbyć. Chmura tego nie robi. To nie ma sensu.
Widzimy wszystkich tych klientów, którzy mają 20, 30, 50, 100 tablic i są one wykorzystane w 40%, 50%, 30%. Chcę zacząć od zwiększenia ich do 70% lub 80%, a to właśnie chce zrobić Fusion.
Kiedy zaczynaliśmy projekt Fusion, skupiliśmy się na wdrożeniach typu greenfield. To było najłatwiejsze i nie musieliśmy się martwić o starsze środowiska. To był błąd. To, co robi nowy Fusion, to wdrażanie typu brownfield. Ludzie, którzy już mają floty, mogą teraz wdrożyć Fusion, a w zasadzie wchłonąć swoją obecną konfigurację i zacząć wdrażać nowe rzeczy dzięki Fusion.
Następna faza umożliwi Fusion bezproblemowe rebalansowanie wszystkich tych tablic. Fusion zacznie zalecać równoważenie obciążenia.
Widziałeś coś z tego w [Pure’s AI] Copilot. To jest zapowiedź techniczna tego lata, ale kiedy zostanie wydany, będzie wyposażony w Fusion. Pomoże Ci uzyskać te informacje o flocie. Pomoże użytkownikom niebędącym ekspertami uzyskać dogłębne informacje o flocie i podejmować znacznie bardziej strategiczne decyzje.
Jakie przeszkody inżynieryjne musiało pokonać Pure, aby Fusion mogło działać w poprzemysłowych środowiskach?
Bo:Najważniejsze jest to, iż można łatwo stwierdzić, iż każdy wolumin i każdy obiekt zostały skonfigurowane dzięki Fusion, więc Fusion wie o tym wszystkim.
Centralna baza danych Fusion może mieć całą tę wiedzę i powiedzieć, iż wszystko jest zgodne z jedną z tych zdefiniowanych klas pamięci masowej. Trudna część z brownfield polegała na tym, iż powiedzieliśmy, iż weźmiemy wszystkie istniejące konfiguracje, i iż je przejmiemy, a następnie przekształcimy w konfigurację Fusion.
Fusion ma pojęcie rzeczy takich jak witryna. Bardzo podobne do niektórych koncepcji chmury. Nie ma informacji o witrynie, które istnieją w istniejącej konfiguracji.
Trzeba było podjąć decyzję, na przykład: „Zaimportujemy wszystko z istniejącej konfiguracji i przeniesiemy to do domyślnego obszaru roboczego”.
Inną koncepcją Fusion jest pomysł, iż możesz mieć przestrzeń roboczą, którą kontrolujesz dzięki swoich klas pamięci masowej, a ja mogę mieć taką, którą kontroluję dzięki mojej. Więc musiał wziąć całą istniejącą konfigurację, wciągnąć ją i utworzyć domyślne ustawienia dla wszystkich tych rzeczy. Wszystkie koncepcje, których wcześniej nie było.
W Kubernetes masz trwałe woluminy i klasy pamięci masowej, a aplikacje mają swoje roszczenia do klas pamięci masowej i trwałych woluminów. Łatwo zobaczyć, jak to działa w Kubernetes, ponieważ Kubernetes jest brokerem, który obsługuje te relacje. Jaki jest odpowiednik tego w Fusion, czy istnieje odpowiednik? Jak to działa?
Bo: Nie, istnieje bardzo duże podobieństwo, i o tym właśnie mówiłem, o witrynach, przestrzeniach roboczych i tego typu rzeczach.
Gdzie chmura, choćby przed Kubernetes, wprowadziła koncepcję witryny lub regionu, chyba można to nazwać strefą dostępności w regionie, tego rodzaju koncepcje do sposobu działania ludzi. A Kubernetes ma podobny zestaw koncepcji i mają tam pewne drobne różnice, ale przyjęliśmy te same rzeczy w Fusion; witryny, strefy dostępności i tego typu rzeczy.
Ponieważ próbujemy stworzyć usługę podobną do chmury, którą można uruchomić lokalnie lub którą można uruchomić lokalnie i rozszerzyć na Pure Cloud Block Store i zasoby w chmurze.
Czy Fusion w podobny sposób zapewnia odpowiednik żądania stałej objętości w aplikacji?
Bo: Trwałe roszczenie woluminu jest bardziej kwestią kontenera, więc to byłoby bardziej Portworx. Ale analogia jest taka, iż normalnie, gdy masz system plików lub wolumin, masz go wyeksportowanego zgodnie z zestawem reguł eksportu, w przypadku systemu plików lub podłączonego do hosta, Fibre Channel, iSCSI, NVMe itd., ale masz to połączenie z hostem.
Można argumentować, iż połączenie hosta jest odpowiednikiem stałej rezerwacji lub stałej relacji. Ponieważ za każdym razem, gdy wyłączasz i restartujesz swoje centrum danych, wraca.
Mapując to, co dzieje się z Kubernetesem, w przypadku złożonego środowiska z wieloma starszymi aplikacjami, w jaki sposób te aplikacje zgłaszają swoje roszczenia do klas pamięci masowej?
Bo:Powiedziałbym, iż przez cały czas używasz Portworx lub czegoś podobnego do zarządzania aplikacjami opartymi na kontenerach.
A co z aplikacjami nieopartymi na kontenerach?
Bo: Aplikacje nieoparte na kontenerach mają na przykład bazę danych składającą się z pięciu woluminów. W konfiguracji macierzy byłoby stałe połączenie skonfigurowane w celu połączenia tych woluminów z tym hostem.
Jedną z rzeczy, które Fusion ma tendencję robić i która jest inna – wracając do tego, o czym mówiłem w kontekście równoważenia rzeczy – jest uzyskanie najlepszego wykorzystania floty. Nie należy brać aplikacji o wysokiej wydajności i umieszczać jej całej w jednej macierzy.
Należy rozmieścić aplikację o wysokiej wydajności w grupie macierzy, a także aplikacje o niższej wydajności w tych macierzach, aby uzyskać równomierne wykorzystanie z perspektywy obciążenia i równomierne wykorzystanie z perspektywy pojemności.
Dawniej, przed Fusion, jeżeli chciałeś utworzyć nową bazę danych, robiłeś to w ten sposób. Mówiłeś na przykład: „Potrzebuję woluminu dziennika, woluminu roboczego i trzech woluminów danych” i normalnie ustalałeś tablicę, która miała dostępną pojemność i wydajność, tworzyłeś te pięć woluminów w tablicy – i być może nie tworzyłeś ich wszystkich idealnie spójnie z każdą inną instancją tej aplikacji – a następnie konfigurowałeś połączenie z tej tablicy do hostów, które będziemy uruchamiać dla tej bazy danych.
W świecie Fusion powiesz: „Chcę tych pięć woluminów dla tej aplikacji”. Możesz mieć szablon dla aplikacji. Albo powiesz: „Chcę tych pięć woluminów i chcę, aby te cztery z nich były klasy A, a ten wolumin roboczy chcę, aby był klasy C, ponieważ nie zależy mi na tworzeniu kopii zapasowej w ten sam sposób”.
Fusion potencjalnie umieści je na pięciu różnych tablicach, ponieważ Fusion znajdzie miejsce w Twojej flocie, a następnie utworzy instancję wolumenu i utworzy instancję połączenia. Dzięki temu będziesz mógł to zrobić w sposób, który zapewni Ci znacznie lepsze wykorzystanie Twojej floty i znacznie większą spójność. Myślę, iż to są dwie największe korzyści.
Wracam do tego, kiedy chcesz coś zmienić i mówisz: „Muszę lepiej chronić się przed ransomware” lub „Muszę lepiej zadbać o kopię zapasową”. Kiedy możesz wnioskować o swoim środowisku, ponieważ jest prostsze, podejmiesz lepszą decyzję.
A potem, oczywiście, kiedy możesz to wdrożyć, po prostu mówiąc: „Chcę zmienić definicję pamięci masowej klasy A, aby kopie zapasowe były tworzone co cztery godziny zamiast co osiem godzin i przejść i zrobić to w całej flocie”. To jest moc, której ludzie nie mają dzisiaj.
