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.
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.
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ší.
Nejprve musíme založit custom zdroje (CRD), tedy rozšířit Kubernetes API o nové objekty popisující datové služby Azure Arc.
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.
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.
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.
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.
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.
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.
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.
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.
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
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
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.
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í.
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.
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.
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.