Prawda o Tanzu – bazodanowo rzecz biorąc

Za górami za lasami za bazami danych, pobili się dwaj DevOps’i poleceniami. Hej DevOps’i nie  bijta się!
Ma Tanzu trzy systemy baz danych – podzielita się.

Tak można zacząć nasz kolejny wpis o Tanzu i jego funkcjonalnościach. Nie jestem pewien czy DevOps’i czy może inni inżynierowie będą zadowoleni z możliwości uruchomienia baz danych w ramach Kubernetesa, ale na pewno jest łatwiej i szybciej. Proces przygotowania środowiska zaprezentujemy w najbliższym Demoleo, a ja kilkoma słowami zapowiem i wprowadzę do tematu.

Z poprzednich publikacji poznaliśmy pewne technikalia związane z vSpherem i Tanzu co przybliżyło temat uruchamiania pod’ów oraz klastrów Kubernetes w ramach vSphere. Teraz idziemy o krok dalej i będziemy uruchamiać bazy danych.

W silnikach siła

Mowa tutaj o silnikach bazodanowych takich jak:

  • MySQL,
  • Postgres 
  • Greenplum.

Jest to element, który dostajemy w ramach licencji Tanzu Advanced. Właśnie VMware Tanzu SQL pozwala na uruchamiania dedykowanych baz danych MySQL i Postgres jako instancje Kubernters albo maszyny wirtualne. Mechanizmy Tanzu SQL with MySQL for Kubernetes i Tanzu SQL with Postgres for Kubernetes są operatorem Kubernetes, który automatyzuje uruchamianie, zarządzanie i operacje na dedykowanych instancjach baz danych uruchamianych w ramach Kubernetes. Jak widzimy te dwa mechanizmy działają w ramach klastrów Kubernetes, a istnieje jeszcze możliwość powoływania i używania instancji MySQL jako maszyny wirtualne. W przypadku MySQLa widzimy większe możliwości niż w przypadku Postgresa ale może się to kiedyś zmieni. Teraz płynnie przejdźmy do omówienia tych oto produktów.

  • VMware Tanzu SQL with Postgres for Kubernetes

zawiera paczki udostępniane na stronie producenta systemu bazodanowego. Mowa tutaj o samym silniku bazodanowym, czyli PostgreSQL oraz komponentach takich jak pgBackRest, pg_auto_failover, psqlODBC i pgjdbc. Dodatkowo mamy Kubernetes Operator, który pozwala nam wdrażać i zarządzać jedną lub wieloma instancjami. Całość tworzy nam paczkę o nazwie Tanzu Postgres. Wspomniana paczka wspiera kilka platform np. TKGI, TKG on AWS, GKE, AKS czy Amazon EKS. Wcześniej warto sprawdzić wersje naszego środowiska – kubectl get nodes -o wide.

  • Następny etap to zainstalowanie Tanzu Postgres Operator.
  • No i żeby było łatwo i przyjemnie możliwości mamy dwie: Instalacja za pomocą Helma
  • albo za pomocą Tanzu CLI.

Jeśli chodzi o pierwszy sposób to tak w skrócie Helm ułatwia zarządzanie aplikacjami Kubernetes. Nie ważne z którego sposobu będziemy chcieli skorzystać musimy mieć dostęp to Tanzu Network w celu pobrania obrazów do lokalnego repozytorium. Jeżeli już mamy to wszystko zainstalowane możemy przejść do uruchamiania instancji Postgres. 

Instancja Postrges

Oczywiście tworząc nową instalację musimy użyć nowego PVC albo, gdy chcemy zrobić aktualizacje używamy już istniejący. Możemy również zainstalować rozszerzenia, aczkolwiek musimy to już zrobić ręcznie. Mowa tutaj o pgAudit, PostGIS czy Orafce. Przechodząc już do funkcji Tanzu Postgres pozwala ona:

  • wykonywać kopie zapasowe na życzenie,
  • używać harmonogramu do wykonania kopii
  • oraz mamy możliwość przywracania in-place oraz do nowej instancji Postgres.
  • Możemy również tworzyć scenariusze Disaster Recovery, tworzyć konfiguracje wysokiej dostępności (HA) jak poniżej.
Postgres HA

Oczywiście potrzebujemy jeszcze monitorować instancje. Również Tanzu Postgres ma taką możliwość, wykorzystując Postgres Exporter czyli nic innego jak Prometheus exporter for Postgres.

Prometheus exporter for Postgres

Odpowiednikiem dla baz danych MySQL jest Tanzu MySQL for Kubernetes.

Funkcjonalności są identyczne jak w poprzednim rozwiązaniu. Możemy uruchamiać pojedyncze instancje, instancje w HA, wykonywać backup i przywracanie, szybką aktualizację itp. Aby powoływać instancje MySQL musimy posiadać Tanzu MySQL Operator, którego możemy zainstalować na dwa sposoby.

  1. Sposobem pierwszym jest instalacja z Tanzu Network Registry, jeżeli mamy dostęp do Internetu lub z pobranego pliku, gdy takiego dostępu nie posiadamy. Później już możemy działać na masową skalę 😉.
  2. Pojedyncza instancja MySQLa jest niezwykle prosta. Składa się z serwisu, poda i aby mieć gdzie przechowywać dane z PVC. Jeżeli chcemy mieć HA to podów jest więcej i dodatkowo mamy proxy jak przedstawiłem na schemacie poniżej.

 

MSQL HA

Monitorowanie MySQL’a jest wykonana analogicznie jak w przypadku Postgres’a

Oczywiście jak wspomniałem wcześniej MySQL’a można uruchamiać nie tylko w klastrach Kubernetes ale również jako dedykowane instancje. W tej sytuacji sprawa jest być może bardziej złożona, ponieważ potrzebujemy kilku nowych elementów. Tutaj do zarządzania i wdrażania wykorzystywany będzie BOSH (to nie ten BOSCH od pralek i innych AGD). Kolejno musimy mieć BOSH Director, BOSH Agent, BOSH UAA czy w przypadku klastrów DNS – BOSH DNS.

Jako ostatni system bazodanowy został Greenplum. Tutaj tylko kilka słów o samym systemie bazodanowym, ponieważ jest on dla mnie nowy.


Przeznaczony do masowego przetwarzania równoległego. Dzięki swojej budowie może działać jako superkomputer bazy danych, który działa superszybko. Tanzu Greenplum możemy uruchamiać w ramach Dell EMC VxRail, AWS, GCP, Azure oraz w środowiskach on-premis. Oprócz odpowiedniego systemu operacyjnego jak RedHat, CentOS czy Ubuntu potrzebujemy również odpowiednio skonfigurowanej sieci (potrzebna jest sieć wewnętrzna i zewnętrzna), DRS, HA a w przypadku vSANu również musimy odpowiednio przygotować politykę dyskową. Instalacje możemy wykonać na kilka sposobów. Standardową jak dla pozostałych przez VMware Tanzu Network, ale również za pomocą OVA dostępnego w Marketplace.

Całe rozwiązanie Tanzu SQL wydaje się być fajną automatyzacją i uproszczeniem, ale czy tak rzeczywiście jest to musicie ocenić sami.
Testujcie, sprawdzajcie i dajcie znać jakie są wasze odczucia, a tymczasem zapraszam na demo Michała, które pojawi się niebawem.

Artykuł został opublikowany w ramach partnerstwa VMware.