Trudno dzisiaj wyobrazić sobie usługę IT, która gdzieś w architekturze nie posiada pamięci masowej. Niezależnie czy jest to klasyczny silos, czy nowoczesna architektura aplikacji 3. generacji dane gdzieś trzeba przechowywać. Automatyzując całe środowisko nie sposób więc zapomnieć o tym właśnie obszarze. Na szczęście w ostatnich latach producenci zadbali również i o ten aspekt.
Czego powinniśmy oczekiwać od macierzy dyskowej czy innych urządzeń w erze automatyzacji? Przede wszystkim możliwości wykonywania części tych czynności, które dzisiaj są Świętym Gralem zespołów administratorskich. Przede wszystkim mówimy tu o tworzeniu nowych wolumenów, usuwaniu, zmienianiu ich wielkości, tworzeniu migawek, czy w końcu konfiguracji replikacji. Oczywiście nie zakładamy przekazania steru osobom, które nie mają odpowiednich kompetencji w zakresie zarządzania pamięcią masową, a tym bardziej klientowi portalu samoobsługowego. Automatyzacja w tym obszarze zmienia zatem sytuację w ten sposób, że administrator, który dotychczas wykonywał wszystkie czynności sam, dziś skupia się na przygotowaniu polityk i procesów, które potem w bezpieczny sposób będą mogły być wywołane przez warstwę automatyzacji w ramach jej zadań.
Warstwa fizyczna wciąż ma duże znaczenie
Można by tutaj zadać pytanie po co to wszystko, skoro wirtualizacja właśnie uprościła ten model? Skoro można używać dysków wirtualnych takich jak VHDX lub VMDK gdzie jest potrzeba na manipulacje fizycznymi wolumenami. Odpowiedzią na to pytanie jest heterogeniczność. Mimo wszechobecnej wirtualizacji nie sposób jest uniknąć komponentów, które pozostały fizyczne. Czy to z powodów wydajnościowych, choć osobiście uważam, że można już dzisiaj wirtualizować nawet ciężkie bazy danych, czy z powodów licencyjnych, co ma miejsce coraz częściej szczególnie przy zaostrzaniu polityk licencyjnych dostawców.
Sytuację zmienia również zastosowanie obiektowej pamięci masowej, szczególnie dla procesów DevOps. Jeśli przyjmiemy, że aplikacje komunikują się z taką pamięcią za pomocą protokołów takich jak S3 czy Azure Storage, chcąc automatyzować środowisko musimy uwzględnić także operacje wykonywane na takiej pamięci. Jeśli więc chcemy powołać do życia kolejną instancję testową, która jako pamięć masową wykorzystuje np. appliance Hitachi Content Platform komunikując się z nim za pomocą S3, to musimy również powołać kolejny kontener danych na tej platformie.
Czego powinniśmy oczekiwać od macierzy dyskowej czy innych urządzeń w erze automatyzacji? Przede wszystkim możliwości wykonywania części tych czynności, które dzisiaj są Świętym Gralem zespołów administratorskich. Przede wszystkim mówimy tu o tworzeniu nowych wolumenów, usuwaniu, zmienianiu ich wielkości, tworzeniu migawek, czy w końcu konfiguracji replikacji. Automatyzacja w obszarze pamięci masowej zmienia zatem sytuację w ten sposób, że administrator, który dotychczas wykonywał wszystkie czynności sam, dziś skupia się na przygotowaniu polityk i procesów, które potem w bezpieczny sposób będą mogły być wywołane przez warstwę automatyzacji w ramach jej zadań.
Aby automatyzacja miała sens, narzędzie musi mieć możliwość realizacji takiego zadania i właśnie dlatego integracja pamięci masowych z platformą automatyzującą jest równie istotna, jak inne obszary infrastruktury. Na szczęście producenci pamięci masowych doskonale o tym wiedzą i dostarczają już odpowiednie wtyczki. Warto więc zwrócić uwagę na to w jakim zakresie będzie obsługiwane przez platformę dane urządzenie.
Systemy pamięci masowych oparte o OpenStack
Weźmy dla odmiany platformę OpenStack, w której najbardziej znanymi komponentami pamięci masowych są Cinder i Swift. Pierwszy z nich odpowiada za obsługę blokowej pamięci masowej, a konkretnie tworzy warstwę abstrakcji dla warstwy mocy obliczeniowej Nova. Cinder wyposażony w klasyczny LVM i wtyczki pochodzące od producentów sprzętu potrafi wykonywać na nim np. utworzyć wolumeny, które w prosty sposób zostaną przedstawione maszynom wirtualnym. Nova przekazuje jedynie zapotrzebowanie na wolumen o określonych parametrach, Cinder rozumie, na której macierzy go szukać i posługując się językiem jej producenta organizuje ten wolumen. Jest w pewnym sensie wirtualizatorem warstwy zarządzania macierzy blokowych.
Rozpatrując rozwiązanie do budowania zautomatyzowanego środowiska w oparciu o OpenStack musimy sprawdzić w jakie operacje Cinder będzie mógł wykonać automatycznie. Przykładowa lista wspieranych operacji dla platformy EMC VMAX:
- • Create, delete, attach, and detach volumes.
- • Create, list, and delete volume snapshots.
- • Copy an image to a volume.
- • Copy a volume to an image.
- • Clone a volume.
- • Extend a volume.
- • Retype a volume.
- • Create a volume from a snapshot.
- • Create and delete consistency groups.
- • Create and delete consistency group snapshots.
- • Modify consistency groups (add/remove volumes).
Z analogiczną sytuacją mamy do czynienia w przypadku komponentów Swift, który odpowiada za pamięć obiektową. Swift pozwala w prosty sposób przechowywać obiekty za pomocą prostego API. W tym przypadku np. platforma obiektowa HCP (Hitachi Content Platform) wprost posiada odpowiednik API OpenStack – HCP HSwift. Podobnie ma się sytuacja w Dell EMC ECS, który obsługuje Swift. Tutaj również należy sprawdzić bardzo wnikliwie jakie operacje będą w ramach danego producenta wspierane. Im lepiej zweryfikujemy szczegóły tych integracji w fazie projektowania i POC tym mniej negatywnych skutków i niespodzianek czeka nas po wdrożeniu projektu. Oczywiście ta sama zasada działania ma zastosowanie w przypadku platform Microsoft, VMware i innych producentów automatyzacji. Jakość integracji z platformą ma tutaj kolosalne znaczenie.
Przenoszenie ciężaru wielu operacji na pamięć masową
Na podobnej zasadzie należy przeanalizować na wybrany sprzęt pozwoli warstwie automatyzacji – czy współpracującej z nią warstwie wirtualizacji – wykorzystać takie dobrodziejstwa pamięci masowych jak VAAI (vSphere API for Array Integration), VASA (vSphere API for Storage Awareness) czy SMI-S (Storage Management Initiative Specification). W uproszczeniu, są to technologie pozwalające przenosić ciężar wielu operacji na pamięć masową, przyspieszając jednocześnie ich wykonywanie. Warto maksymalnie z nich korzystać, gdyż w modelu w pełni zautomatyzowanym liczy się każda optymalizacja.
W platformie OpenStack komponentami pamięci masowych są Cinder i Swift. Pierwszy z nich odpowiada za obsługę blokowej pamięci masowej, a konkretnie tworzy warstwę abstrakcji dla warstwy mocy obliczeniowej Nova. Cinder wyposażony w klasyczny LVM i wtyczki pochodzące od producentów sprzętu potrafi wykonywać na nim np. utworzyć wolumeny, które w prosty sposób zostaną przedstawione maszynom wirtualnym. Nova przekazuje jedynie zapotrzebowanie na wolumen o określonych parametrach, Cinder rozumie, na której macierzy go szukać i posługując się językiem jej producenta organizuje ten wolumen.
Szczególnym przypadkiem zastosowania tych technologii są tzw. VVOLs czyli wirtualne wolumeny, które są wprost realizacją koncepcji Software-Defined Storage, niejednokrotnie opisywanej na łamach ITwiz. Jeśli to klient i jego usługa determinują wymagania funkcjonalne, wydajnościowe i pojemnościowe to w środowisku zautomatyzowanym tym bardziej wymaga się precyzyjnego dostosowania tych parametrów z dużą granularnością, nawet do pojedynczego dysku. W zasadzie tylko SDS na dzisiaj tak skutecznie łamie bariery tworzone przez klasyczne LUNy.
Separacja środowiska zautomatyzowanego
Innym aspektem, na który zdecydowanie warto zwrócić uwagę to możliwość separacji środowiska zautomatyzowanego. Oczywiście w idealnym świecie dobrze byłoby posiadać jednolite, automatyczne centrum danych, ale w praktyce najczęściej zaczynami od małej instalacji, która z czasem rośnie i staje się wiodąca. Zwykle na początku projektu mamy w lepszy lub gorszy sposób poukładany świat, spisane (i nie spisane) procedury obsługi, nomenklaturę nazw i adresów i inne głęboko zakorzenione przyzwyczajenia. Tymczasem automatyzacja będzie posługiwać się koszmarną ilością bezdusznych identyfikatorów, obiektów, których rozumienie będzie niesamowicie trudne, przez co proces ten „oddamy” w ręce maszyny.
O ile jeszcze takie podstawowe sprawy jak nazwy maszyn wirtualnych, czy wolumenów dyskowych będziemy mogli parametryzować i zmusić automat do ich generowania według zadanego klucza to identyfikatory na przykład sieci, grup czy wirtualnych urządzeń generowanych na macierzy dyskowej pozostaną jedynie zbiorem pokrętnie dobranych cyfr. Z pomocą przychodzi tutaj… wirtualizacja wirtualizacji, a dokładniej utworzenie macierzy w macierzy. Na takie rozwiązanie pozwalają już zaawansowane systemy operacyjne pamięci masowych, umożliwiając nawet utworzenie osobnego, wirtualnego numeru seryjnego urządzenia.
O ile jeszcze takie podstawowe sprawy jak nazwy maszyn wirtualnych, czy wolumenów dyskowych będziemy mogli parametryzować i zmusić automat do ich generowania według zadanego klucza to identyfikatory na przykład sieci, grup czy wirtualnych urządzeń generowanych na macierzy dyskowej pozostaną jedynie zbiorem pokrętnie dobranych cyfr. Z pomocą przychodzi tutaj… wirtualizacja wirtualizacji, a dokładniej utworzenie macierzy w macierzy. Na takie rozwiązanie pozwalają już zaawansowane systemy operacyjne pamięci masowych, umożliwiając nawet utworzenie osobnego, wirtualnego numeru seryjnego urządzenia. Wtedy można, co najmniej w okresie przejściowym zachować istniejący świat infrastruktury zamykając jego zautomatyzowaną część na wydzielonym poligonie.
Zapewnienie ciągłości działania
Budując automatyczne centrum danych nie można zapomnieć o zabezpieczeniach w zakresie ciągłości. I w tym obszarze sprawa się nieco komplikuje, bo przecież jeden aspekt to replika danych, drogi to automatyczne przełączanie całości infrastruktury, która z tymi danymi pracuje. Tutaj warto sięgnąć po rozwiązania takie jak VMware Site Recovery Manager, które uprzednio zaprogramowane za nas zorganizują zarówno przełączenie lub test. Co ważne a często wręcz krytyczne, takie procedury muszą być precyzyjnie udokumentowane, a ich realizacja musi wygenerować wnikliwe raporty. Szerzej o tym aspekcie będziemy pisać w kolejnych odsłonach tego cyklu. Tym razem skupmy się na szczególnym przypadku, który upraszcza wiele, czyli klaster rozproszony.
Zarówno platformy wirtualizacyjne, takie jak vSphere czy Hyper-V wspierają takie rozwiązanie. Polega ono na tym, że zasoby dyskowe z dwóch centrów danych udostępniane są serwerom w postaci jednolitych wolumenów. Z punktu widzenia wirtualizacji jest to jeden wolumen, jeden klaster, a wysoka dostępność działa dokładnie tak samo jakby klaster pracował w jednym miejscu. Co więcej inteligencja zaszyta w rozwiązanie sama dba o to, aby zapis odbywał się po tej stronie, po której fizycznie znajduje się maszyna wirtualna. Wcześniej jednak pisaliśmy o tym, że automatyzujemy nie tylko maszyny wirtualne… I zdecydowanie to podtrzymujemy! Takie rozproszone wolumeny można stosować nawet dla systemów fizycznych, a także dla platform poza x86, czyli np. IBM Power/AIX.
Kluczowym ograniczeniem dla takich systemów jest jedynie opóźnienie, a to wynika z odległości. W grę wchodzą zatem architektury, które kwalifikują się do replikacji synchronicznej, czyli – jak się przyjęło – do ok. 100 km. Jednak są wyjątki! W ostatnim czasie za pomocą technologii GAD (Global Active Device) można oficjalnie (i ze wsparciem producenta) rozciągnąć klaster na 200 km. Dzięki zastosowaniu klastra rozciągniętego na poziomie warstwy automatyzacji nie musimy się martwić o programowanie procesów przełączania ośrodków.
Podsumowując, pamięć masowa w procesie automatyzacji infrastruktury, to – podobnie, jak w przypadku wirtualizacji – kluczowy element. Na pewno warto rozważyć opisane tutaj aspekty, ale także – a raczej przede wszystkim – na dalszych etapach ściśle współpracować z producentem.
Autorami tekstu są Krzysztof Waszkiewicz i Daniel Wasyliszyn, architekci.
