By ftake @
2021-05-08 12:06
この記事は小江戸らぐ 5月のオフな集まり の発表ネタです。
2回目の夏を迎えるに当たり、自宅ファイルサーバーの熱とファンの音が気になり、モニタリングしてみることにしてみました。今回は他の用途でも興味があった Grafana を使ってみました。Grafana は CPU 使用率やメモリ使用量といったハードウェアから、データベースやアプリケーションの性能といった様々なメトリクスを可視化・分析するための Web アプリケーションです。インタラクティブに操作できたり、かっこいい見た目だったりで、最近よく見かけます。
小江戸らぐ向け注記: よくカロスさんの発表に出てきます。K8s のクラスタやラズパイの環境センサーの表示で使っていますね。
Grafana Cloud
今回はちょっと横着して、Grafana の SaaS である Grafana Cloud を使いました。Grafana といえば、多くの場合、メトリクス収集と時系列データベース機能を持つ Prometheus と組み合わせ、これら2つをどこかにインストールして使います。Grafana Cloud では Grafana 本体と Prometheus のデータベース部分は Grafana Cloud で動いているものを使うことができます。データの収集は Prometheus からデータベース部分などを簡略化した Grafana Agent で収集できます。
気になるお値段ですが、Free プランがあります。メトリクスの保持期間は2週間というのがポイントになりますが、ちょっと試して見るには十分です。無料プランの主なスペックはこんな感じです:
10,000 系列（種類）までの Prometheus または Graphite のメトリクス 50 GB のログ 14日間のメトリクスとログの保持期間 3人までのチームメンバー アカウントを作るためにクレジットカードなどの情報は特に必要ありません。 Grafana Cloud のページでアカウント作成に進み、GitHub などの SSO でログインすればすぐ準備完了です。
メトリクス収集
次に、メトリクスの収集を始めましょう。雷のアイコン（⚡） > Walk through をクリックすると、スクリーンショットのように Grafana Cloud がサポートしているプラットフォームのメトリクス収集を簡単にセットアップできるガイドが用意されています。今回は Linux Server を使用します。Prometheus では Node Exporter と呼ばれているものです。
Linux Server をクリックすると、セットアップするためのスクリプトが表示されます。「Choose your OS」には openSUSE が見当たりませんが、「RedHat – based」で OK です。Go言語で実装されたアプリなので、システムライブラリにほとんど依存していません。
あとは、その下に表示されたスクリプトを実行すれば OK です。Grafana Agent の RPM のインストールと設定ファイルの作成、起動まで一気に行われます。セットアップが終わると、最初から用意されているダッシュボードに収集した情報が表示されます。（datasource で grafanacloud-xxxx-prom を選択）
ダッシュボードの作成
もちろん、ダッシュボードを自分で組み立てることもできます。ここではパネルを配置し、Visualization を Time Series にして次を追加してみました。収集されているメトリクスの一覧がドロップダウンメニューに表示されるので、ここからそれっぽいものを選んで追加することができます。
node_cpu_scaling_frequency_hertz instance:node_cpu_utilisation:rate1m node_hwmon_temp_celsius 各系列のスタイルや、単位、Y軸の設定は、ちょっとわかりにくいですが Overrides タブで系列を選んで個別に設定できます。
このファイルサーバーは普段ほとんどアイドル状態なのですが、CPU クロックが思った以上に落ちていないことが分かりました。ファンコントロールのターゲット温度が45℃設定なのですが、55℃くらいをキープしているようです。
おわりに
Grafana Cloud を使って自宅ファイルサーバーの監視を簡単にしてみました。そして Grafana Agent が CPU 時間を他と比較して使ってしまっていますので、場合によっては収集する項目を減らすなどを考えたほうが良いかもしれません。
Category
openSUSE ,
サーバ |
受け付けていません
By ribbon @
2021-04-28 18:11
前回は T でしたが、今回は S です。
パッケージ名 scout
> scout bin sdl -config
リポジトリ | パッケージ | パス | バイナリ
----------------------------------+--------------+----------+------------
zypp ( openSUSE -20210325 -0 ) | libSDL -devel | /usr /bin | sdl -config
zypp ( download .opensuse .org -oss ) | libSDL -devel | /usr /bin | sdl -config
というような感じになります。
パッケージ名 sc
パッケージ名 socat
socat tcp4 -listen : 8089 , reuseaddr , fork tcp : 172.16.z.zz : 13
結果はこうなります。
% telnet 172.31.y.yy 8089
Trying 172.31.y.yy...
Connected to susedev .
Escape character is '^]' .
28 APR 2021 18 : 00 : 15 JST
Connection closed by foreign host .
このようにすることで、2段階のログインをしなくとも172.16.z.0 のセグメントにあるマシンに接続することが出来ます。
Category
openSUSE ,
Tips ,
サーバ ,
デスクトップ |
受け付けていません
By Syuta Hashimoto @
2020-12-23 01:30
諸事情で、MicroOSのルートにbtrfsの機能でディスクを追加したのですが、balasceを実行しようとすると「read onlyだよ」と警告が。
ユーザ会slackに投げてみた所、武山さんから「transactional-update shellの中ならいけるのでは？」との助言を頂きました。
結論
成功
コマンド
transactional-update shell
transactional-updateそのもののアップデートが行われた後、独自のシェルに移行しました。
transactional update #
この状態で書き込み可能になります。書き込み後、シェルを抜けてrebootすれば反映されるしくみですね。
btrfs balance /
前後の状態を撮り損ねてしまったのですが、無事にbalanceされてました。
transactional-updateの真価はまだ味わえてないので、ロールバック等含め、近いうちにまとめて検証してみたいですね。
そもそも、transactional-update shellが一体何をどうしているのかも追えていない・・・
By ftake @
2020-12-18 01:59
この記事は openSUSE Advent Calendar 18日目です。 残り、あと少しですが、まだ埋まってなく3年連続の完走がピンチ。みなさんご協力下さい。
この内容は小江戸らぐ のオフな集まり2月と、オフだけどオンライン開催だった5月の発表内容でもあります。
ことの始まり
この春、ファイルサーバーを組みました。これまで、写真等の大きめのファイルはデスクトップに置いていましたが、タブレットやスマフォを使用しているとデスクトップを起動しないこともあり、アクセスするにはちょっと不便でした。かといってクラウドに上げるには容量が大きいのが現状です。
このとき、電源の故障で引退した、ちょっと古いけどまだ使える一式（Socket FM2 の M/B, AMD A4-5300 APU, DDR3 8 GBメモリ）があったのと、鹿さん から、使わなくなったファイルサーバー用の MiniITX ケースを頂いたので、これでファイルサーバーを組んでみることにしました。
RAID カード調達
HDD は NAS 用のものを適当に買うとして、1度はRAID 5 や 6 で組んでみたい！ということで、RAID カードを探しました。一般のご家庭（誤変換）では、数万円クラスのカードを使っているかと思いますが、この「ありあわせ構成」には不釣り合いです。安く入手する方法としては、ヤフオクなどでサーバーから抜き取ったものを探す手がありますが、あまりに古いと EFI に対応していなかったり、4 KB セクタや 2TB の壁にあたる可能性があります。また、中古品はキャッシュ保護用のバッテリーが死んでいる可能性もあります。
そこで今回は eBay で3世代前の Adaptec ASR-71605 の新古品を買ってみました。キャッシュ保護用のコンデンサ付き、送料込みで 8500円くらいでした。ドライバはカーネルに入っているのですぐに使えます。
意外と高かったのがケーブルでした。Mini SAS HD から SATA ×4にするもので、Amazon で 2500 円くらいでした。
OS インストール
セットアップに困ることはないはずが、openSUSE 15.1 をインストールすると、なぜかディスプレイドライバが固まります。いろいろ試したところ modeset ドライバを ACPI が有効な状態で使うとダメなようです。今回はディスプレイはほとんど使わないので nomodeset を起動オプションに追加することで回避しました。（modeset ドライバだと、コンソールの解像度がディスプレイにあわせて変わるので良いのですが…）
ファイルサーバーの設定
Samba は入れるだけです。とっても簡単ですね。
Btrfs にしてスナップショットを取るようにしました。このあたりはOSCのスライド や Geeko Magazine を見てください。
iSCSI サーバーは4月に書いた別の記事 で。
バックアップの設定
重要なディレクトリを選んで USB 接続の HDD に1日に1回、Snapper の最新スナップショットからバックアップを取るようにしました。単純に rsync でコピーを取ります。Btrfs のバックアップといえば、ファイルシステムレベルで差分転送をできる btrfs send があります。しかし、ファイルシステムが壊れてしまった場合に、btrfs send を行うとバックアップも壊れる可能性があるのではないかと考え、今回は使用しませんでした。
タイマーとスクリプトはこのような感じです。タイマーの時間は Snapper の実行中にならないように気をつける必要があります。
backup-to-usb-disk.timer
[ Unit ]
Description =Back up files to USB disk daily
[ Timer ]
OnCalendar =*-*-* 6 : 20 : 00
Persistent =true
[ Install ]
WantedBy =timers .target
backup-to-usb-disk.service
[ Unit ]
Description =Back up files to USB disk
[ Service ]
ExecStart =/usr /local /sbin /backup -to -usb -disk .sh
Type =oneshot
backup-to-usb-disk.sh
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
#!/bin/bash
set -e
if [ ! -f /var /backup /backupdisk ] ; then
echo "Back up disk is not found"
exit 1
fi
# home
snapshot_root =/home /.snapshots
cd $ snapshot_root
latest_snapshot =` ls -1 | grep "[0-9]*" | sort -nr | head -n 1 ` /snapshot /
echo "creating back up of /home/.snapshots/$latest_snapshot"
if [ ! -e $ latest_snapshot ] ; then
echo "Snapshot directory error"
exit 1
fi
target_dir =/var /backup /home /
rsync -va --delete $ latest_snapshot $ target_dir
様子見中
Snapper が走る時（おそらく）に btrfs-cleaner がかなり CPU を使うので、試しに Quota 機能を無効にしています。
おわりに
簡単にではありますが、ファイルサーバーを構築したときのいろいろを紹介しました。このファイルサーバーでは、先日書いた Spotify クライアント も動いています。新たな活用を始めたら記事にしたいと思います。
Category
openSUSE ,
サーバ |
受け付けていません
By Syuta Hashimoto @
2020-12-17 01:00
私はKubicでKubernetesを構築しているのですが、Kuibcをアップデートしてkubeletのバージョンが1.19に上がったはずなのにもかかわらず、kubectl get nodeでずっとバージョンが1.18となっていて悩んでいました。
結論
/etc/sysconfig/kubelet に設定されている KUBELET_VERを、1.18から1.19に変更する
調査
パッケージを確認
まず、パッケージがなんのバージョンが入っているかを確認します。
kubic1-host:~ # zypper se kubelet
どうやら、1.17、1.18、1.19、と、いろいろなバージョンが入ってるようです。
今見たら、1.20も入ってますね。
使ってるバイナリを確認
kubic1-host:~ # type kubelet
kubelet is hashed (/usr/bin/kubelet)
ふむふむ。/usr/bin/kubelet、ですね。
こういう実行ファイルはスクリプトの場合があったりするので、種別を調べてみます。
kubic1-host:~ # file /usr/bin/kubelet
なるほど、スクリプトっぽいですね。
中身を確認します。
kubic1-host:~ # cat /usr/bin/kubelet
どうやら、/etc/sysconfig/kubeletの値を参照しているようです。こちらを確認してみます。
kubic1-host:~ # cat /etc/sysconfig/kubelet
なるほど、KUBELET_VERが定義されています。nodeのバージョンが低いときは、ここが1.18となっていましたので、それを1.19に更新しました。
それからKubernetesを起動すると、見事バージョンが1.19にあがってました。
今なら1.20に上がる予感・・・・
メーリングリスト
最近忙しいこともあって、なかなかメーリングリストなどの情報源にあたれず・・・もしかしたら、こういったことはとうに情報共有されていたのかもしれません。また、この設定がKubic独自なのか、一般的なのか、といったことも追いきれておらず。追って調査したいと思います。
そもそもの使い方
アップデートで使い続けるのではなく、折を見て最新プリメイドイメージに乗り換えていく運用が今っぽいのかも・・・・・
Category
サーバ ,
未分類 |
受け付けていません
By ribbon @
2020-12-08 00:02
仮想環境プラットフォームとしてとても便利なProxmox VEですが、バージョン6.3が出ています。
変更点は https://pve.proxmox.com/wiki/Roadmap#Proxmox_VE_6.3 にありますが、順当に少しずつ機能が強化されてるという所でしょうか。あと今回は、Proxmox Backup Server との統合機能がメインかな。
地味にモダンなインタフェースになっているところもあります。例えば、今までプルダウンメニューで選択していたブート順の指定が、GUIのドラッグ&度ラップで出来るようになっていたりします。
日本語訳については最新版が反映されていないようです(画面ではテスト環境なので最新版になってますが、まだバグがありますね)。
そのほか、クラスタ回りとかストレージ回りで少しずつ改良がされているようです。ただ、openSUSE をゲストOSにしてテストするような場合にはあまり影響はないようです。
Category
Tips ,
サーバ ,
仮想化 |
受け付けていません
By Syuta Hashimoto @
2020-12-07 00:10
某LUGで、Kubernetesのメモリ使用量を気にされていたので、測ってみました。
結論
masterノードはKubernetes起動後、1.3G前後のメモリを使用。workerは、コンテナを動かせば動かしただけメモリを使用。15pod程度では、2つのworkerでそれぞれ1G使わない程度でした。
方針
KVM上にKubicを展開して、そこでKubernetesを動かします。
VMの起動のみの状態、Kubernetesを起動した状態、いくつかのpodを動かした状態、で、freeや、topのメモリ使用量上位10のプロセスを拾ってみます。
また、Kubernetes起動後はcrictl statsの結果も見てみます。今回、IDを名前で置き換えていますのでご注意下さい。（通常のcrictl statsですと、IDのみの表示となり名前は表示されません。）
環境
Kubernetes KVM上で動かす OSはKubic CPU数 master 2 worker 1 メモリ それぞれ 3G Kubernetes 1.19.4 ホストopenSUSE 15.2 CPU Ryzen 3900 メモリ 32G Kubic ・・・openSUSEプロジェクトで開発している、Kubernetes専用OSです。Tumbleweedをベースにしていて、Kubernetesを動かすことに焦点を絞ったパッケージ構成＆システム設定。プリビルドなイメージが毎日のように公開されるため、ignitionなどの初期設定ツールを使って手早く最新Kubernetesを展開できます。
Ryzen 3900・・・コア数12なので、VMは結構たてられます。目指せおうちクラウド。
ちなみに、saltstackのマスター用VMを別途立てていて、各ゲストは基本的にそこから制御しています。（今回のコマンド実行は直接各ゲストで行いました。）
VMの起動のみ
master
worker1
worker2
利用可能メモリが、3台とも2.5G程度であることがわかります。
Kubernetes起動後
Kubernetesとネットワークアドオンのweaveを起動します。
master
worker1
worker2
masterがさらに1G程使用しました。workerは数百程度の使用にとどまっています。
podを幾つか起動した後
15個程podを走らせてみます。
走らせたサービスは、Promeheus、Grafana、DokuWiki、Nextcloud、Harborなどです。
master
worker1
worker2
masterの使用量はほとんどかわりませんが、動いたpod分、両workerのメモリが使用された感じです。
参考までに、pod一覧です。
感想
色々と検証しているときは、clairが1G以上メモリを使ったりしていましたが、今回計測しているときは100Mいかないぐらいでした。当然ですが、podの起動だけでなく、実際に使ってみた時のメモリ使用量なんかが実運用上では参照値になると思います。
まだ、プロセスやコンテナの動作と使用メモリとの関連を掴みきれてないので、追って調査してみたいと思います。コンテナのメモリとディスクの関連も。
なお、今回動かしたサービスの殆どはiscsiのPersistentVolumeに接続しています。このあたりの方法も消費リソースと関わっていそうですね。
Kubernetesってメモリ使うんだよなー、よし、各ノードに6G割り当てるか、とかやっていたのですが、今回の計測で今の所3Gでも大丈夫なことがわかったので、設定を変更しました。やはり適切な設定は適切な計測から、ですね。ちなみに、Kubernetesでpodを動かす時に、CPU使用率やメモリ使用量の上限などを設定できます。このあたりについてもおいおい見ていきたいと思います。
Category
openSUSE ,
Tips ,
サーバ |
受け付けていません
