SQL Server の情報をメインに Microsoft 製品の勉強内容を日々投稿
Azure Stack HCI 上で Windows Server を実行する場合、Windows Server サブスクリプション という利用形態で Windows Server OS を実行することができ、詳細については次のドキュメントで解説が行われています。
価格については Azure Stack HCI の価格 に記載されており、Azure Stack HCI のホスト OS の物理コアによる月額コストとなり、サブスクリプションモデルで、Windows Server OS の仮想マシンを実行する場合は、実行している仮想マシン単位のコストを考慮しなくてもよくなります。
ライセンス オプションの比較 に、次のように記載されていますが、CAL についても不要となり、シンプルな考え方で Windows Server を使用することができるようになります。
Windows Server サブスクリプションについても Azure Stack HCI の 60 日間の評価内容に含まれており、評価期間内であれば、コストを発生させることなく検証をすることができます。
Azure Virtual Desktop (AVD) for Azure Stack HCI の検証環境については、Announcing Jumpstart HCIBox でアナウンスされた、Nested Hyper-V の環境を使用して構築することができます。
Azure Arc や Azure Stack HCI の評価環境ですが、Nested 環境として作るのもよいのですが、物理環境で構築したほうが、より実運用に近くなるのではないでしょうか。
ということで、自宅で AVD for Azure Stack HCI の検証環境を、物理環境で作った際のメモを。
SQL Server 2012 は、2022/7/12 にサポートが終了し、現在は、拡張セキュリティ更新プログラム (ESU) でのみ Microsoft からサポートされるソフトウェアとなりました。
SQL Server の ESU については SQL Server 用の延長セキュリティ更新プログラムとは で情報がまとめられており、Azure Stack HCI 上で動作させた場合の特典についても本情報で次のように記載されています。(拡張セキュリティ更新プログラム (ESU) について でも情報がまとめられています)
Azure サービス。 オンプレミス サーバーを次のいずれかの Azure サービスに移行する場合は無料であり、既定で有効になります。
Azure Stack HCI で Azure 特典 を使用している場合、Azure サービスでの動作となり、ESU を特典として利用することができるため、Windows Server / SQL Server の ESU 提供を無償で受けることが可能となります。
当ブログでも、Windows Server 向けの ESU については、次の投稿で検証を実施していました。
SQL Server 向けについては SQL Server 2012 対応した内容の検証ができていなかったのですが、SR で問い合わせをさせていただきながら情報を把握することができたので、本投稿でまとめておきたいと思います。
ESU では、次の二つの内容が提供されています。
現状セキュリティ更新プログラムは提供されていないため、本投稿で確認している内容については、セキュリティ更新プログラムの提供を受けるための事前準備までとなります。
ライフサイクルサポートが終了した、Windows Server / SQL Server については、2008 以降は ESU (拡張セキュリティ更新プログラム) が提供されます。
ESU は有償のプログラムですが、Windows Server 2012、2012 R2、および SQL Server 2012 のサポート終了に備える で次のように記載されている通り、Azure のサービスと組み合わせることで無償で提供を受けることができます。
無料の拡張セキュリティ更新プログラムは、Azure Virtual Machines、Azure 専用ホスト、Azure VMWare Solution、Azure Nutanix Solution、Azure Stack Hub/Edge/HCI などの Azure のお客様が利用できます。
今回、検証で使用する Azure Stack HCI も対象となっており、Azure Stack HCI 上で動作している仮想マシンについても無償で ESU を受けることができる環境となります。
Build 2022 で Azure Stack HCI 単一ノードクラスターの一般提供 (GA) がアナウンスされました。
以前、別の評価に使用していた NUC8v7PNH が 1 台空いたので、この Azure Stack HCI 単一ノードの評価用としてセットアップして、ESU の適用を行うことろまで確認できましたので、情報をまとめておきたいと思います。
ESU については、次のドキュメントを参考にするとよいかと思います。
検証用で使用している Intel NUC Gen11 (NUC11TNHv70L) の CPU は、Core i7-1185G7 が搭載されており、VT-x が使用できますので、Nested Hyper-V (入れ子になった仮想化) を使用することができる CPU となっています。
Nested Hyper-V の有効化については、入れ子になった仮想化による仮想マシンでの Hyper-V の実行 で公開されており、今回使用している NUC のような物理ハードウェア上にインストールした仮想マシンで実行するのであれば、
ことで、Nested Hyper-V を使用することができます。
しかし、今回使用している Gen 11 の NUC では、上記の対応を行っても Nested Hyper-V を有効化することができませんでした。
Twitter でつぶやいたところ次のようなアドバイスをいただき、教えていただいた方法を使用することで Nested Hyper-V を有効化することができました。
こちらのコマンドではどうでしょうか？
Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V,RSAT-Hyper-V-Tools-Feature,Microsoft-Hyper-V-Management-PowerShell
— いまにゅー (@imanyu) December 17, 2021
今後も何回か同じ事象でハマりそうなので、対応方法を残しておきたいと思います。
タイトルの通りですが、AKS on Azure Stack HCI の k8s を v1.21.2 で展開した後に、コントロールプレーンノードを再起動した後に k8s が起動しないという事象が発生しました。
「systemctl status kubelet」で状態を確認してみると、次のようなエラーが発生し、kubelet が起動していませんでした。
Nov 30 11:35:13 moc-lrr9qh1ew26 kubelet[741]: E1130 11:35:13.936688 741 kuberuntime_sandbox.go:68] "Failed to create sandbox for pod" err="rpc error: code = Unknown desc = failed to get sandbox image \"ecpacr.azurecr.io/pause:3.2\": failed to pull image \"ec
pacr.azurecr.io/pause:3.2\": failed to pull and unpack image \"ecpacr.azurecr.io/pause:3.2\": failed to resolve reference \"ecpacr.azurecr.io/pause:3.2\": failed to authorize: failed to fetch anonymous token: unexpected status: 401 Unauthorized" pod="kube-system
/etcd-moc-lrr9qh1ew26"
Nov 30 11:35:13 moc-lrr9qh1ew26 kubelet[741]: E1130 11:35:13.936713 741 kuberuntime_manager.go:790] "CreatePodSandbox for pod failed" err="rpc error: code = Unknown desc = failed to get sandbox image \"ecpacr.azurecr.io/pause:3.2\": failed to pull image \"ec
pacr.azurecr.io/pause:3.2\": failed to pull and unpack image \"ecpacr.azurecr.io/pause:3.2\": failed to resolve reference \"ecpacr.azurecr.io/pause:3.2\": failed to authorize: failed to fetch anonymous token: unexpected status: 401 Unauthorized" pod="kube-system
/etcd-moc-lrr9qh1ew26"
Nov 30 11:35:13 moc-lrr9qh1ew26 kubelet[741]: E1130 11:35:13.936764 741 pod_workers.go:190] "Error syncing pod, skipping" err="failed to \"CreatePodSandbox\" for \"etcd-moc-lrr9qh1ew26_kube-system(8e85a0583a698c64f4daca0d375decfa)\" with CreatePodSandboxErro
r: \"Failed to create sandbox for pod \\\"etcd-moc-lrr9qh1ew26_kube-system(8e85a0583a698c64f4daca0d375decfa)\\\": rpc error: code = Unknown desc = failed to get sandbox image \\\"ecpacr.azurecr.io/pause:3.2\\\": failed to pull image \\\"ecpacr.azurecr.io/pause:3
.2\\\": failed to pull and unpack image \\\"ecpacr.azurecr.io/pause:3.2\\\": failed to resolve reference \\\"ecpacr.azurecr.io/pause:3.2\\\": failed to authorize: failed to fetch anonymous token: unexpected status: 401 Unauthorized\"" pod="kube-system/etcd-moc-l
rr9qh1ew26" podUID=8e85a0583a698c64f4daca0d375decfa
Nov 30 11:35:13 moc-lrr9qh1ew26 kubelet[741]: E1130 11:35:13.981869 741 kubelet.go:2291] "Error getting node" err="node \"moc-lrr9qh1ew26\" not found"
Nov 30 11:35:14 moc-lrr9qh1ew26 kubelet[741]: E1130 11:35:14.035070 741 event.go:273] Unable to write event: '&v1.Event{TypeMeta:v1.TypeMeta{Kind:"", APIVersion:""}, ObjectMeta:v1.ObjectMeta{Name:"moc-lrr9qh1ew26.16bc4fcc087e2ba6", GenerateName:"", Namespace
:"default", SelfLink:"", UID:"", ResourceVersion:"", Generation:0, CreationTimestamp:v1.Time{Time:time.Time{wall:0x0, ext:0, loc:(*time.Location)(nil)}}, DeletionTimestamp:(*v1.Time)(nil), DeletionGracePeriodSeconds:(*int64)(nil), Labels:map[string]string(nil),
Annotations:map[string]string(nil), OwnerReferences:[]v1.OwnerReference(nil), Finalizers:[]string(nil), ClusterName:"", ManagedFields:[]v1.ManagedFieldsEntry(nil)}, InvolvedObject:v1.ObjectReference{Kind:"Node", Namespace:"", Name:"moc-lrr9qh1ew26", UID:"moc-lrr
9qh1ew26", APIVersion:"", ResourceVersion:"", FieldPath:""}, Reason:"Starting", Message:"Starting kubelet.", Source:v1.EventSource{Component:"kubelet", Host:"moc-lrr9qh1ew26"}, FirstTimestamp:v1.Time{Time:time.Time{wall:0xc061a0f98b59afa6, ext:11623948584, loc:(
*time.Location)(0x74be600)}}, LastTimestamp:v1.Time{Time:time.Time{wall:0xc061a0f98b59afa6, ext:11623948584, loc:(*time.Location)(0x74be600)}}, Count:1, Type:"Normal", EventTime:v1.MicroTime{Time:time.Time{wall:0x0, ext:0, loc:(*time.Location)(nil)}}, Series:(*v
1.EventSeries)(nil), Action:"", Related:(*v1.ObjectReference)(nil), ReportingController:"", ReportingInstance:""}': 'Post "https://10.5.0.2:6443/api/v1/namespaces/default/events": EOF'(may retry after sleeping)
Nov 30 11:35:14 moc-lrr9qh1ew26 kubelet[741]: E1130 11:35:14.082278 741 kubelet.go:2291] "Error getting node" err="node \"moc-lrr9qh1ew26\" not found"
Nov 30 11:35:14 moc-lrr9qh1ew26 kubelet[741]: I1130 11:35:14.104104 741 trace.go:205] Trace[2056973426]: "Reflector ListAndWatch" name:k8s.io/client-go/informers/factory.go:134 (30-Nov-2021 11:35:02.280) (total time: 11824ms):
Nov 30 11:35:14 moc-lrr9qh1ew26 kubelet[741]: Trace[2056973426]: [11.824032031s] [11.824032031s] END
Nov 30 11:35:14 moc-lrr9qh1ew26 kubelet[741]: E1130 11:35:14.104137 741 reflector.go:138] k8s.io/client-go/informers/factory.go:134: Failed to watch *v1.RuntimeClass: failed to list *v1.RuntimeClass: an error on the server ("") has prevented the request from
succeeding (get runtimeclasses.node.k8s.io)
Nov 30 11:35:14 moc-lrr9qh1ew26 kubelet[741]: E1130 11:35:14.182788 741 kubelet.go:2291] "Error getting node" err="node \"moc-lrr9qh1ew26\" not found"
kubelet の起動のパラメーターを見ると、「–pod-infra-container-image=ecpacr.azurecr.io/pause:3.2」が指定されており、上記のメッセージでも pause コンテナーのイメージのアクセスでエラーが発生しているようでした。
ACR に格納した Helm のチャートで SQL Server の展開を行おうとした場合のメモ。
AKS on HCI でも一部の展開には Helm が使用されているので、概要はつかんでおかないとと思った次第です。
この辺の情報を取り掛かりにすれば、手を動かすことはできそうです。
AKS on Azure Stack HCI (OS は HCI OS ではなく、Windows Server 2019) に対して、Azure DevOps パイプラインを実行しようと思った際の作業した内容のメモを。
最終的には Azure Arc Enabled Kubernetes の GitOps を使用することになるのかなとは思うのですが、今回はそこまでは試せていません。
AKS on Azure Stack HCI を Windows Server 2019 の 1 ノード環境ではありますが、1 台起動したままにすることができそうなので、この機会に勉強を兼ねてメモを残しておきたいと思います。
AKS on Azure Stack HCI は、検証用途であれば 1 台の Windows Server 2019 上で動作させることができます。(Azure のサポート内で AKS on Azure Stack HCI のサポートを受ける場合は、OS に Azure Stack HCI OS を使用していたほうがスムーズになりますので、リソースに余裕がある場合は、HCI OS で環境を構築していたほうが良いかと)
64 GB / 4 Core (HT : 8 Core) の NUC が 1 台あれば、構築することができ、Windows Server 上で Kubernetes を展開することができます。
私のような今まで Windows をメインに触ってきたエンジニアでも Kubernetes の検証環境を容易に作ることができますので、k8s の勉強環境にも活用できるかと。
基本的には、Azure Stack HCI の Azure Kubernetes Service のドキュメント のドキュメントを確認しながら、勉強した内容を適宜更新していきたいと思います。
私の場合は、仕事の領域が「SQL Server のデータベースエンジン」となりますので、AKS on HCI を使用するのは、Azure Arc Enabled SQL Managed Instance を検証することが目的であり、Enabled SQL Managed Instance 観点の情報も記載しています。
Azure Stack HCI では、 Azure Kubernetes Service (AKS) を実行することができます。
この AKS 上で、Azure Arc Enabled Data Services を動作させることもでき、展開用のテンプレートについては、Azure Data Studio でも、提供されています。 
検証用途で自宅の NUC を使用して環境を構築できるか検証して、構築ができましたのでその際のメモを残しておこうと思います。
Azure Stack HCI は、HCI ((Hyper Converged Infrastructure) を Windows 環境で実現するものです。
標準的な HCI というと構成済みの環境をベンダーから購入して導入するイメージですが、現時点では、Azure Stack HCI Preview の登録 から、Azure Stack HCI OS (HCI OS の Previw をダウンロードして、検証環境を構築することもできるようになっていますので、検証環境を自由に構築することが可能です。
最終的に、Hyper-V のゲスト OS として、HCI クラスターを構築し、その HCI クラスター上で、Azure Arc Enabled Data Services の検証を行うことは可能でした。
