Cephadm で構築した Ceph クラスタのホストをメンテナンスする手順です。 今回は 3 台構成 (ceph1/ceph2/ceph3)の Ceph クラスタのうち、ceph1 をメンテナンス対象としています。 バージョン 本記事で利用している Ceph のバージョンです。 $ ceph version ceph version 16.2.7 (dd0603118f56ab514f133c8d2e3adfc983942503) pacific (stable) 事前確認 はじめに、メンテナンス対象ホストを停止してもクラスタに影響が出ないかチェックします。 ceph orch host ok-to-stop コマンドを使うことでチェックしてくれます。 $ ceph orch host ok-to-stop ceph1 ALERT: Cannot stop active Mgr daemon, Please switch active Mgrs with 'ceph mgr fail ceph1.eqphaf' 今回はアラートが出力されてしまいました。 ceph1 の MGR がアクティブ状態となっているためホストの停止ができないようです。 次のコマンドでスタンバイ状態の MGR へフェイルオーバーします。 $ ceph mgr fail ceph1.eqphaf フェイルオーバーが成功したか Ceph クラスタの状態を確認します。 ceph -s cluster: id: dc32e976-d0ea-11ec-bac3-dca6329a21a7 health: HEALTH_ERR (snip) services: mon: 3 daemons, quorum ceph1,ceph2,ceph3 (age 4m) mgr: ceph3.mlmhqd(active, since 9s), standbys: ceph1.eqphaf, ceph2.rlgifo osd: 6 osds: 5 up (since 68m), 5 in (since 12h) 今回は ceph1 の OSD が落ちている状態なのでエラーが出ていますが無視してください。 ...

Ceph OSD が落ちるなどして PG (Placement Group) でエラーが出た場合の修復手順です。 我が家のラズパイ Ceph は頻繁に OSD が落ちます。 そのせいで PG のエラーも多発しており、都度対応しています。 PG のエラー状況に応じた修復手順をこの記事に掲載していきます。 免責 本記事では個人利用の Ceph クラスタに対して実施した手順を掲載しています。 PG の修復はデータ損失を伴う可能性があります。 掲載内容によって生じた損害等の一切の責任を負いかねますのでご了承ください。 （大事なことなので） バージョン 本記事で利用している Ceph のバージョンです。 $ ceph version ceph version 16.2.7 (dd0603118f56ab514f133c8d2e3adfc983942503) pacific (stable) 状況確認 OSD が落ちた Ceph クラスタの状況を確認します。 ceph health detail コマンドで Ceph クラスタの状況を確認すると、PG_DAMAGED や PG_DEGRADED といったアラートが上がっていて、PG に active+clean+inconsistent などがマークされています。 $ ceph health detail (snip) [WRN] OBJECT_UNFOUND: 4/1615 objects unfound (0.248%) pg 2.1f has 1 unfound objects pg 2.3 has 1 unfound objects pg 2.7 has 1 unfound objects pg 2.e has 1 unfound objects [ERR] OSD_SCRUB_ERRORS: 6 scrub errors [ERR] PG_DAMAGED: Possible data damage: 4 pgs recovery_unfound, 4 pgs inconsistent pg 2.3 is active+recovery_unfound+degraded, acting [7,5,0], 1 unfound pg 2.7 is active+recovery_unfound+degraded, acting [1,0,6], 1 unfound pg 2.9 is active+clean+inconsistent, acting [7,1,0] pg 2.d is active+clean+inconsistent, acting [0,1,7] pg 2.e is active+recovery_unfound+degraded, acting [6,5,4], 1 unfound pg 2.15 is active+clean+inconsistent, acting [4,6,5] pg 2.1b is active+clean+inconsistent, acting [0,1,7] pg 2.1f is active+recovery_unfound+degraded, acting [6,4,1], 1 unfound [WRN] PG_DEGRADED: Degraded data redundancy: 12/4845 objects degraded (0.248%), 4 pgs degraded pg 2.3 is active+recovery_unfound+degraded, acting [7,5,0], 1 unfound pg 2.7 is active+recovery_unfound+degraded, acting [1,0,6], 1 unfound pg 2.e is active+recovery_unfound+degraded, acting [6,5,4], 1 unfound pg 2.1f is active+recovery_unfound+degraded, acting [6,4,1], 1 unfound PG の状態に応じて対処していきます。 ...

Cephadm のアラート CEPHADM_FAILED_DAEMON を消す方法です。 ...

自宅ラボでは Cephadm を使ってラズパイに Ceph クラスタを構築して遊んでます。 今回は Ceph の Zabbix モジュールを使って Zabbix からラズパイ Ceph クラスタを監視できるようにします。 ただモジュールを有効化するだけでは Zabbix から監視できなかったので、手順を残します。 ちなみにラズパイ Ceph クラスタは CentOS/RockyLinux/AlmaLinux 各種 OS を使った混合環境です。 本当はクラスタ構築の話から投稿したかったのですが、モチベの関係で先にこのネタから投稿します。 Zabbix モジュール有効化 Ceph Manager Daemon (MGR) は、モジュールという形でダッシュボード機能や他製品との連携機能を提供しています。 Cephadm 自体も「Orchestrator モジュール」を使って Ceph を管理しているようです。 公式のモジュール一覧は ここ （でいいんですかねぇ…？） MGR のモジュールの中に「Zabbix モジュール」があるので、このモジュールを有効化して使います。 ceph mgr module enable zabbix Zabbix モジュールのパラメータのうち、以下の 2 つを設定します。 zabbix_host: Zabbix サーバのホスト名 identifier: Zabbix に登録する Ceph クラスタ名 ceph zabbix config-set zabbix_host zabbix.example.com ceph zabbix config-set identifier raspi-ceph 今回はその他のパラメータはデフォルト値のまま使いました。 以下のコマンドでパラメータを確認します。 ...

2021 年も残すところ数日ということで、少し早いですが今年 1 年間の振り返りと来年の抱負を掲げます。 ...

Red Hat が提供するエンタープライズなコンテナ・プラットフォーム「OpenShift」がシングルノードに対応したようです。 Meet single node OpenShift: Our newest small OpenShift footprint for edge architectures The cloud native approach to developing and deploying applications is increasingly being adopted in the context of edge computing. However, edge workloads and use cases span a myriad of locations, technical requirements, and physical footprints. www.redhat.com そうとなれば試してみたい欲求が抑えられませんよね？ というわけで要件を満たす機器を選定するところから SNO (Single Node OpenShift) を導入してみました。 ハードウェア要件 SNO をインストールするには以下のスペックが必要です。 プロファイル CPU メモリ ストレージ 最低限 8 vCPU コア 32 GB 120 GB 普通(?) の OpenShift だとコントロールプレーンで 4 コア/16 GB、コンピュートノードで 2 コア/8 GB が最小要件となっているので、一台辺りのスペックは高くなってしまいます。 一台でコントロールプレーンとコンピュートノードの役割を担うのでそこら辺は仕方ないですね。 ...

Ansible AWX バージョン 18.0 から AWX Operator を使うインストール方法に変更されました。 https://github.com/ansible/awx-operator AWX Operator を使うと Kubernetes クラスタへの AWX デプロイが簡単にできます。 標準的な設定では AWX 関連のコンテナをまとめた Pod と一緒に PostgreSQL Pod もデプロイされますが、今回は AWX Operator 管理外の PostgreSQL インスタンスと連携するように AWX をデプロイします。 環境情報 ソフトウェア バージョン Kubernetes 1.21.2 AWX 19.3.0 AWX Operator 0.13.0 Zalando Postgres Operator 1.6.3 AWX Operator AWX Operator は公式の マニュアル 手順通りにインストールしていきます。 特筆する点はないのでマニュアルを参照してください。 PostgreSQL AWX で利用する PostgreSQL インスタンスは Zalando Postgres Operator を使って用意します。 Operator のインストール方法は下記の投稿を参照してください。 Zalando Postgres Operator を試してみた - 勇往邁進 以下の postgresql リソースのマニフェストで、AWX 用の PostgreSQL インスタンスがデプロイされます。 ...

NGINX Ingress Controller と MetalLB を使った Ingress の構築に失敗していた話です。 背景 自宅ラボの Kubernetes クラスタでは、NGINX Ingress Controller と MetalLB をデプロイしています。 これらを使って、Ingress リソースに NGINX Ingress Controller 向け LoadBalancer Service の External-IP を割り当てて、各種サービスを Ingress 経由で公開しています。 一方、Kubernetes クラスタとは別に自宅ラボ用の DNS サーバを構築しており、夏季休暇中に CoreDNS から PowerDNS に入れ替える作業をしました（この話は別途投稿したいと思います）。 するとどうでしょう、DNS サーバの入れ替え作業後に Ingress で公開していたサービスに接続できなくなってしまいました。 状況 Ingress リソースを確認したところ、設定されている IP アドレスが想定していたアドレスと異なっていました。 想定アドレスは上述の通り「NGINX Ingress Controller 向け LoadBalancer Service の External-IP」です。 しかし、実際には「Kubernetes クラスタの Worker Node の IP アドレス」が設定されていました。 $ kubectl get ingress -A NAMESPACE NAME CLASS HOSTS ADDRESS PORTS AGE argocd argocd-server-ingress <none> argocd-ingress.k8s.nnstt1.work 192.168.2.29 80, 443 22h monitoring grafana <none> grafana.k8s.nnstt1.work 192.168.2.29 80 20h monitoring k8s <none> prometheus.k8s.nnstt1.work 192.168.2.29 80 20h sandbox sample-app <none> sample-app.k8s.nnstt1.work 192.168.2.29 80, 443 20h # 192.168.2.29 は Worker Node の IP アドレス Node Port のように Worker Node の IP アドレスでアクセスしても NGINX Ingress Controller のサービスには到達できないため、Ingress で指定したサービスにも接続できていませんでした。 ...

(2021/5/18 追記) Operator のインストールしかしてないじゃん、ってことでタイトル変更しました。 実際に Operator で構築した Minio を試して、続編として投稿したいと思います。 前回の投稿から 3 ヶ月ほど空いてしまいました。 その間に、誕生日に Japan Rook Meetup で登壇したり… 本日の登壇資料です。改めてありがとうございました！ #japanrookhttps://t.co/WZzoEYEnku — ののし (@nnstt1) April 2, 2021 CKA (Certified Kubernetes Administrator) の資格を取ったり… CKA 受かりました！俺たちの Kubernetes はこれからだ！完 pic.twitter.com/ivkWe9FxzG — ののし (@nnstt1) May 3, 2021 したのですが、まったくブログにアウトプットできてませんでした。 現在は CKAD (Certified Kubernetes Application Developer) に向けて勉強中なのですが、裏で MinIO Operator を触ってみたので気晴らしに久しぶりの投稿をします。 MinIO とは MinIO は、Amazon S3 互換のオープンソースオブジェクトストレージです。 MinIO | Enterprise Grade, High Performance Object Storage プライベート/ハイブリッドクラウドの標準オブジェクトストレージとなることを前提とした設計のようです。 そのためか、公式サイトではファイルシステムやブロックストレージには結構キツい物言いをしている感じがします（個人の感想です）。 ハイブリッドクラウドストレージは、パブリッククラウドで確立されたモデルに従い、パブリッククラウドプロバイダーは全会一致でクラウドネイティブオブジェクトストレージを採用しています。 パブリッククラウドの成功により、ファイルとブロックストレージは事実上時代遅れになりました。 すべての新しいアプリケーションは、POSIXではなくAWS S3API用に作成されています。 クラウドネイティブテクノロジーのようにスケーリングして実行するには、古いアプリケーションをS3 API用に書き直し、コンテナ互換になるようにマイクロサービスにリファクタリングする必要があります。 ...

Kubenews #8 を視聴していたら Velero というツールの話題が出て、そういえば試そうと思って手付かずのままだったなぁと思い出し、試せるのはいつになるかなぁと Twitter で呟いたら「今でしょ！」とも言われたので、Velero を試してみました。 Velero とは Velero は、Kubernetes クラスタのリソースと永続データをバックアップ、リカバリ、移行するためのツールです。 VMware のプロジェクトとして管理されており、VMware Tanzu (VMware の Kubernetes 製品群) の一員です。 vmware-tanzu/velero: Backup and migrate Kubernetes applications and their persistent volumes Velero は Kubernetes クラスタに対して以下のような使い方ができます。 バックアップ・リストア 別クラスタへの移行 本番環境のクラスタを別環境に複製 Velero の特徴としては、Kubernetes API を使ってバックアップ・リストアをする API-driven な点があります。 他の Kubernetes 用バックアップツールはクラスタ内の etcd を直接参照してバックアップ・リストアするようで、その点が異なります。 API-driven なバックアップツールには以下のようなメリットがあります。 名前空間、リソースタイプ、ラベルによってバックアップ・リストア対象を柔軟に選択可能 マネージド K8s クラスタの場合、etcd を直接参照できずバックアップ・リストアできないことがあるが、API 経由なら可能 別の etcd にリソースが保存されていてもバックアップ・リストア可能 正直なところ、3点目はどのような場合を想定しているのか理解できていません…。 また、Velero は Kubernetes のリソースだけでなく、永続データもバックアップ・リストアの対象とすることができますが、今回はリソースを対象にしたバックアップ・リストアのみ試しています。 オブジェクトストレージの用意 Velero はバックアップデータをオブジェクトストレージに格納します。 Amazon S3 や Azure Blob Storage といったクラウドサービスとしてのオブジェクトストレージを使ってもよいのですが、今回はオンプレ環境の K8s クラスタ内に2種類のオブジェクトストレージを用意しました。 ...