Przegląd architektury w Azure typu LLD, część pierwsza

Obok StackOverflow Driven Development czy Hype Driven Development ostatnio możemy wyróżnić też CV Driven Development oraz LinkedIn Driven Development. LinkedIn od CV Driven Development różni się tym, że jego efekty kończą jako artykuły na rzeczonym portalu z informacją co takiego fajnego zaprojektowałem/zrobiłem w pracy. Sam LinkedIn coraz częściej wygląda jak na poniższym obrazku, więc warto się zastanowić czy aby na pewno to co czytamy na sens.

Pisane i publikowane na szybko. Za gramatykę i język nie odpowiadam, do czasu korekty ;-)

Coraz częściej natrafiam właśnie na artykuły na temat architektury systemów na LinkedIn. Moją uwagę przykuł wpis #Aks #Kubernetes #Docker #Containers to build a truly global solution wraz z pewną chyba produkcyjną architekturą. Patrząc się na nią i nie zgadzając się z autorem postanowiłem dokonać jej przeglądu tak jak na co dzień robię to dla klientów.

„Publikację” można znaleźć tutaj i tutaj.

W tym wpisie zajmę się częścią bazodanową, a w kolejnym zajmę się resztą aplikacji.

Autor nie pisał nic o specyficznych wymaganiach (niby coś wspominał o MSDTC w komentarzach, ale potem wyłączył komentarze). Zakładam, że takiego wymagania nie ma, bo SQL Server na Linux aktualnie nie wspiera produkcyjnie MSDTC.

MSDTC support on Linux was introduced in SQL Server 2019 preview.

W architekturze baza danych jest trzymana na klastrze Azure Kubernetes Service (AKS) składającym się z trzech węzłów. Cytując:

Production cluster is self-protected on the container level. If SQL Pod goes down system will recreate on the same on another Nod. If Nod goes down system will recreate pod on another Nod. By the way, the same strategy is working in HA SQL cluster. When heartbeat from Master doesn’t respond another server starts. This process brings some data loss, but there is no magic behind.

High-level presentation of High Availability MsSQL kubernetes cluster. Three Nodes one pod service and nodes always on. The cluster will migrate pod in case pod od node failed. The is no reason to create MsSQL HA. Kubernetes, containers are HA itself. All MsSQL databases are stored on persistent volumes. When stateless service goes down, and up - all data are in place.

Czyli na klastrze AKS występuje jeden pod z bazą danych działający jako Deployment (stateless) wraz z zamontowanymi do poda dyskami. Żaden klaster bazodanowy tylko pojedyncza instancja.

Cały problem z tą konfiguracją jest właśnie użycie bazy danych jako stateless z wykorzystaniem wolumenów. Niestety Kubernetes nie posiada żadnych mechanizmów, które dają wysoką dostępność takiej konfiguracji.

Dobrym przykładem jest przetestowanie takiej konfiguracji w dwóch przypadkach: planowym wyłączeniem węzła np. wymagany jest restart co zdarza się w Azure oraz symulacja awarii.

Na potrzeby testu instalację SQL Server na Kuberentes dokonałem za pomocą Helm korzystając z poniższego polecenia.

helm install --name mymssql stable/mssql-linux --set acceptEula.value=Y --set edition.value=Developer --set persistence.enabled=true

Pierwszy przypadek można przetestować za pomocą drain node. Bezpieczne przełączenie bazy na drugi węzeł to około 6 minut (pobieranie obrazu zajmuje tylko około 1 minuty)

Drugi przypadek, czyli awarię łatwo zasymulować „wyrywając maszynę z prądu”. Azure z poziomu cli oraz API pozwała na brutalne włączenie maszyny. Nagranie zajmuję 36:11 i w jego trakcie doszło tylko do fail, over nie zadziałał. Fault tolerance, High Availability, Fully redundant jest tylko połowicznie – fault działa dobrze! ;-)

Powód takiego działania to użycie wolumenów z Azure Disk i sposób ich działania razem z Deployment, który zachowuje się prawidłowo, ale nie z perspektywy bazy danych. Faktem jest, że Kubernetes sam z siebie nie nadaje się z dobrze do usług stanowych, co w wyważony sposób opisuje Google na swoim blogu:

Running a database on Kubernetes is closer to the full-ops option, but you do get some benefits in terms of the automation Kubernetes provides to keep the database application running. That said, it is important to remember that pods (the database application containers) are transient, so the likelihood of database application restarts or failovers is higher. Also, some of the more database-specific administrative tasks—backups, scaling, tuning, etc.—are different due to the added abstractions that come with containerization.

When choosing to go down the Kubernetes route, think about what database you will be running, and how well it will work given the trade-offs previously discussed. Since pods are mortal, the likelihood of failover events is higher than a traditionally hosted or fully managed database. It will be easier to run a database on Kubernetes if it includes concepts like sharding, failover elections and replication built into its DNA (for example, ElasticSearch, Cassandra, or MongoDB).

Z aspektu wysokiej dostępności implementacją nie ma w ogóle sensu, bo nie działa w tej konfiguracji.

To co w zamian?

Można rozważyć dwie opcje – maszyna wirtualna z SLA na pojedynczą instancję lub Azure SQL Database managed instance.

Porównując kosztowo maszyna wirtualna z dyskami premium (warunek dla SLA) wypada najtaniej od strony Azure. Trzeba doliczyć jeszcze koszty utrzymania maszyny i konfiguracji, ale śmiało można założyć, że są takie same jak dla opisanego klastra AKS.

Azure SQL Database managed instance – zakładając, że posiadamy już licencje na SQL Server z SA i przenosimy je do chmury to w porównaniu do tak opisanego klastra AKS wypada podobnie kosztowo, ale w przypadku managed instance jest mniej pracy do wykonania przy utrzymania niż w AKS. No i oczywiscie usługa jest wysokodstępna, z wbudowanym backupem oraz możliwością łatwego skonfigurowania replikacji do drugiego regionu.

Podsumowując – od strony bazy danych, architektura przedstawiona przez autora wpisu nie spełniała opisanych przez niego założeń.

Jeśli interesuję Cię Kubernetes to zapisz się do nas tutaj lub na KursK8s.pl