Azure Arc pro datové služby aneb cloudová databáze ve vašem vlastním Kubernetes
Jaká je hybridní strategie Microsoftu a o čem je Arc? O tom jsem psal v článku Pohled na hybridní svět IT nově i s Azure Arc před rokem. Dnes už jsou k dispozici první komponenty řešení a tak se na ně společně podíváme. Začneme tématem myslím velmi zajímavým - datové cloudové služby provozované ve vašem Kubernetes clusteru, tedy Azure Arc for Data Services.
Na rozdíl od Azure Arc for Servers jsou hybridní datové služby v preview a neočekávám, že jsou těsně před spuštěním. Jak uvidíte lze si vyzkoušet základní stavební bloky řešení, ale z pohledu pohodlnosti nasazení a propojení s cloudem v preview většina věcí chybí. Přesto myslím velmi přínosné si vyzkoušet a začít se s konceptem seznamovat, protože očekávám, že třeba tak za půl roku se může řešení dostat do produkčního stádia … a to uteče jak voda.
Připomeňme co je Azure Arc for Data Services
Smyslem řešení je nabídnout cloudové datové služby způsobem, kdy běží na Kubernetes clusteru, který jim dáte. Může to být samozřejmě AKS v Azure, ale nedává to moc smysl, když tam je stejná služba jako plný PaaS, tedy se všemi SLA, masivní škálovatelností, více možnostmi včetně globální replikace a bez starání se infrastrukturu a její zabezpečení. Když ale jde o on-premises prostředí, hosting nebo jiný cloud, proč místo tradičního nasazení databáze nevyužít cloudový model? To platí o verzi SQL (kupujete službu, ne nějakou konkrétní verzi - engine je trvale aktuální), automatickém patchování, nafunkování a sfukování výkonu, monitoringu z cloudu i licencování podle aktuálního používání místo nákupu klíčku na 3 roky.
Aktuální a budoucí způsoby provisioningu a správy
Budoucí stav jsem viděl v jednom demíčku na Ignite konferenci a spočívá v tom, že Kubernetes cluster se do Azure napojí přes Azure Arc for Kubernetes a při vytváření Azure SQL si kromě regionu můžu vybrat svůj on-prem Kubernetes cluster. To pro představu co Arc znamená je naprosto ideální, ale tento režim v rámci preview ještě není.
To co je k vyzkoušení je režim bez přímého napojení, tedy řešení nevyžadující trvalé spojení s Azure. Umím si představit, že i to bude scénář plně validní pro některé zákazníky. Jde tedy o to vytočit příslušné zdroje v Kubernetes, k čemuž je potřeba nainstalovat control plane celého systému Azure for Data services a následně control plane služeb (dnes SQL a PostgreSQL) a ty pak nahodí komponenty samotné databáze. Já v dnešním článku, protože jsem člověk spíš od Kubernetu než od dat, použiji přímé nahození Kubernetes prostředky. Pro dataře je ale možné systém rozjet přímo z datového notebooku v Azure Data Studio případně s využitím příkazové řádky azdata.
Po vytvoření těmito metodami zatím Azure o vaší databázi nic vědět nebude. Metadata a metriky musíte v rámci preview nahrát do Azure ručně spuštěním CLI příkazu - ale to je mi prozatím jedno, zajímá mě hlavně jak to funguje pod kapotou a do finálního uvedení se tyhle věci jistě vyřeší.
Instalace kontroleru (přes Kubernetes objekty)
Nejprve musíme založit custom zdroje (CRD), tedy rozšířit Kubernetes API o nové objekty popisující datové služby Azure Arc.
1
2
3
4
5
6
kubectl create -f https://raw.githubusercontent.com/microsoft/azure_arc/master/arc_data_services/deploy/yaml/custom-resource-definitions.yaml
customresourcedefinition.apiextensions.k8s.io/datacontrollers.arcdata.microsoft.com created
customresourcedefinition.apiextensions.k8s.io/postgresql-11s.arcdata.microsoft.com created
customresourcedefinition.apiextensions.k8s.io/postgresql-12s.arcdata.microsoft.com created
customresourcedefinition.apiextensions.k8s.io/sqlmanagedinstances.sql.arcdata.microsoft.com created
Další komponentou, kterou Arc potřebuje je bootstraper. To je jednoduchý Pod, který spusťme v dedikovaném namespace.
1
2
3
4
5
6
7
kubectl create namespace arc
kubectl create -n arc -f https://raw.githubusercontent.com/microsoft/azure_arc/master/arc_data_services/deploy/yaml/bootstrapper.yaml
serviceaccount/sa-mssql-controller created
role.rbac.authorization.k8s.io/role-bootstrapper created
rolebinding.rbac.authorization.k8s.io/rb-bootstrapper created
replicaset.apps/bootstrapper created
Dále budeme potřebovat vytvořit jméno a heslo pro kontroler, které uložíme jako Kubernetes Secret.
1
2
3
4
5
6
printf tomas > ./username
printf Azure12345678 > ./password
kubectl create secret generic controller-login-secret -n arc \
--from-file=./username \
--from-file=./password
rm ./username ./password
V Azure si připravím resource group.
1
az group create -n arc-resources -l westeurope
Datový kontroler nahodíme definováním speciálního resource datacontroller. V následujícím YAML budete muset možná změnit pár údajů jako je číslo subskripce nebo název resource group či region.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
apiVersion: arcdata.microsoft.com/v1alpha1
kind: datacontroller
metadata:
generation: 1
name: arc
spec:
credentials:
controllerAdmin: controller-login-secret
serviceAccount: sa-mssql-controller
docker:
imagePullPolicy: Always
imageTag: public-preview-sep-2020
registry: mcr.microsoft.com
repository: arcdata
security:
allowDumps: true
allowNodeMetricsCollection: true
allowPodMetricsCollection: true
allowRunAsRoot: false
services:
- name: controller
port: 30080
serviceType: LoadBalancer
- name: serviceProxy
port: 30777
serviceType: LoadBalancer
settings:
ElasticSearch:
vm.max_map_count: "-1"
azure:
connectionMode: Indirect
location: westeurope
resourceGroup: arc-resources
subscription: mojesubscriptionid
controller:
displayName: arc
enableBilling: "True"
logs.rotation.days: "7"
logs.rotation.size: "5000"
storage:
data:
accessMode: ReadWriteOnce
className: default
size: 15Gi
logs:
accessMode: ReadWriteOnce
className: default
size: 10Gi
Aplikuji YAML a můžeme sledovat, jak se kontroler vytváří s využitím perzistentních volume a StatefulSet.
1
kubectl apply -f datacontroller.yaml -n arc
Podívejme se, co v Kubernetes vzniklo. Jsou tady Pody, které mají na starost řízení, monitoring a logování celého Azure Arc for Data services.
Služby jsou nasazeny jako StatefulSet, tedy stavové služby s vysokou dostupností a perzistencí, což poznáme i podle toho, že si řešení vzalo perzistentní Volume z Azure.
Poznamenejme si i vystavené služby, protože na nich najdeme ovládací API i monitoring.
Kontroler si můžeme připojit do Azure Data Studio.
SQL Managed Instance v Kubernetes
Kontroler máme připraven, vyzkoušejme si nahodit Microsoft SQL. Můžeme to udělat z Azure Data Studio.
Já ale znovu použiji přímé nasazení přes Kubernetes objekty.
Jako Secret si připravím heslo pro svou databázi.
1
2
3
4
5
6
printf "tomas" > ./username
printf "Azure12345678" > ./password
kubectl create secret generic tomsql-login-secret -n arc \
--from-file=./username \
--from-file=./password
rm ./username ./password
Databázová služba je dostupná je speciální typ zdroje sqlmanagedinstance.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
apiVersion: sql.arcdata.microsoft.com/v1alpha1
kind: sqlmanagedinstance
metadata:
name: sql
spec:
limits:
memory: 4Gi
vcores: "4"
requests:
memory: 2Gi
vcores: "2"
service:
type: LoadBalancer
storage:
backups:
className: default
size: 5Gi
data:
className: default
size: 5Gi
datalogs:
className: default
size: 5Gi
logs:
className: default
size: 1Gi
1
kubectl apply -f sql.yaml -n arc
Databázový engine používá StatefulSet.
¨
Pro perzistenci dat je použit Volume a SQL lze publikovat jako službu ať už interně nebo v mém případě i externě.
Také se můžeme na naši SQL Managed Instance podívat v Azure Data Studio.
Logy jsou dostupné zatím přes Grafana, tedy můžete si je prohlédnout i bez Azure. V budoucnu budou automaticky posílány do Azure, kde budete moci celý systém řídit a vizualizovat.
https://52.236.17.112:30777/grafana
Totéž se týká logů, které můžete lokálně prohlížet v Kibana.
https://52.236.17.112:30777/kibana
Azure Database for PostgreSQL Hyperscale
Druhou službou v preview Azure Arc for Data services je Azure implementace scale-out PostgreSQL postavená na Citus technologii. Jde tedy o více databázových instancí, které si rozdělý data mezi sebou a přinesou tak vysoký výkon a hlavně škálovatelnost, takže jste schopni vyřešit miliardy řádků nebo podporu multi-tenantní aplikace jako jsou SaaS služby, které chcete svým zákazníkům nabídnout.
Nejprve si opět připravíme heslo do databáze.
1
2
3
4
printf "Azure12345678" > ./password
kubectl create secret generic tompsql-login-secret -n arc \
--from-file=./password
rm ./password
Znovu se bude jednat o speciální Custom Resource Definition, které Azure Arc for Data services kontroler porozumí.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
apiVersion: arcdata.microsoft.com/v1alpha1
kind: postgresql-12
metadata:
generation: 1
name: tompsql
spec:
engine:
extensions:
- name: citus
scale:
shards: 3
scheduling:
default:
resources:
limits:
cpu: "4"
memory: 4Gi
requests:
cpu: "1"
memory: 2Gi
service:
type: LoadBalancer
storage:
backups:
className: default
size: 5Gi
data:
className: default
size: 5Gi
logs:
className: default
size: 1Gi
Pošleme do clusteru.
1
kubectl apply -f psql.yaml -n arc
Nahodí se StatefulSet a několik instancí databáze s disky.
Koukneme kde služba běží a můžeme se připojit z Azure Data Studio.
Případně kouknout na telemetrii v Grafana.
Vysoká dostupnost
Všimněte si, že aktuálně řešení nabízí schopnost recovery při havárii, ale je tam určité riziko. Mířím na to, že v preview je databáze v jedné compute instanci a má připojený perzistentní disk. V případě havárie nodu se databáze spustí jinde, data se připojí a engine se znovu rozjede. To samozřejmě nějakou dobu trvá a je tady určitě riziko, že v Kubernetes clusteru nebude dostatečná kapacita pro spuštění Podu někde jinde. Není to pravděpodobné, ale stát se to může. To co jsem si dnes vyzkoušel je zárodek nižší tieru služby - něco jako general purpose.
V plánu je i vyšší varianta služby, která bude používat replikační technologii na úrovni databáze (například AlwaysOn v případě SQL) a půjde tak o tři běžící instance každá se svou kopií dat (shared nothing architektura). Tohle řešení nabídne ještě lepší dostupnost a méně dopadů věcí typu upgrade verze databáze a tak podobně. Tento pokročilejší tier, třeba se bude nazývat business critical, si vyzkoušíme hned jak bude v rámci preview k dispozici.
Azure Arc for Data services je pro mě nesmírně zajímavá služba pro hybridní situace. Stále platí, že databázi je nejlépe komplet přenechat profesionálům, tedy pořídit si jí jako platformní službu v cloudu. Pokud ale skutečně musí běžet u mě, v mé továrně, ropné plošině, v mém kamionu, pobočce, na poli či v lese, stačí mi Kubernetes cluster na to, abych Azure databázové služby rozjel. Vyzkoušet si to v preview se zatím neobroušenými hranami můžete už dnes.