haproxyのアクセスログをfluentdに食わせるところでドハマリ中。haproxyのログが変な形式だしrsyslog経由だしIPv6だしrubyの正規表現あんまり詳しく知らないので何度やってもparseに失敗してエラー吐く。ちゃんとfluentdを調べないと。。。
タグ: debian
Gluasterfsからお引っ越し
Mastodon+ねこ卓+このBlog+オンセンを動かしていたGlusterfsのクラスターが凄まじく不安定(理由はファイル数多過ぎ)でしょっちゅうダウンして冗長化している意味なかったので、DRBD9＋NFSにお引っ越し。
pcsでClusterとNodeを作成した後は、こんな感じでresourceを作成して終わり。
本当は、SplitBrain対策のためにstonishとcorosyncとdrbdのネットワークを冗長化して、DRBDを3レプリカにしてQuorumを使えるようにすればより完璧だけどそれらはおいおい考える。
(世の中の開設blogのどれもこれもが思考停止でとりあえずstonishを無効化というのはいかがな物か)
pcs resource create FsNFS Filesystem \
device="/dev/drbd/by-res/resource0/0" \
directory="/export" \
fstype="btrfs" \
--group flavorGroup
pcs resource create nfsService ocf:heartbeat:nfsserver \
nfs_shared_infodir="/nfslibs" \
op start timeout="10s" \
op stop timeout="10s" \
op monitor interval="10s" timeout="10s" on-fail="restart" start-delay="20s" \
--group flavorGroup
pcs resource create exportfs_NFS ocf:heartbeat:exportfs \
clientspec="xxx.xxx.xxx.xxx/24" options="async,rw,no_root_squash" directory="/export" fsid="root" \
--group flavorGroup
pcs resource create VirtualIPv6 IPv6addr ipv6addr=xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx cidr_netmask=64 --group flavorGroup
pcs resource create VirtualIP IPaddr2 ip=xxx.xxx.xxx.xxx cidr_netmask=24 --group flavorGroup
pcs constraint order set FsNFS FslibNFS VirtualIP nfsService exportfs_NFS
これで、IPV6もちゃんとFailoverできるようになってたので、あとはIPv6でもNFSをExportするのとハートビートもIPV6で定義したいところ。ハートビートはLinkLocal使えば簡単だしね。
(世の中の開設blogのどれもこれもが思考停止でとりあえずIPv6を無効化というのはいかがな物か)
DRBD9とlinstorのメモ
drbdmanageがすっごく不安定なので、linsotrを試してみたメモ。
基本は、3Ware社のドキュメント通りで大丈夫だけど、ビルド部分でドハマリした。
LINBITのGitリポジトリから、drbd-9.0,linstor-server,linstor-client,linstor-api-py,drbd-utilsを取得して、dpkg-buildpackage -bでビルド。masterブランチから直接ダウンロードするとビルドエラーになるし、linbit社のDownloadページからtarballをダウンロードするとdebianディレクトリがなくパッケージが作れないので、リリースタグの付いているブランチを取得する。
(これでめっちゃハマった)
依存関係は逐次潰しながらインストールしていった時のログを残してなかったけど、busterにあるパッケージをaptするだけで基本OK。
パッケージをaptでインストールしたら、drbd.service, linstor-controller.service, linstor-satellite.serviceがsystemdに登録されるので、enable化とstartを行う。
# VG作成
vgcreate drbdpool /dev/vdb1
# LV作成
lvcreate –thin -L 15G drbdpool/thinPool
# node登録
linstor node create testvm [IPアドレス]
# Storage Pool登録
linstor storage-pool create lvmthin testvm testpool drbdpool/thinPool
# Resource登録(確認コマンドは、resource listじゃなくて、resource-definition list)
linstor resource-definition create testResource
# Volume登録(確認コマンドは、volume listじゃなくて、volume-definition list)
linstor volume-definition create testResource 2G
# 登録したResourceの作成(–auto-place 1は、冗長化なし)
linstor resource create testResource –auto-place 1
その後、snapshotを実行したらカーネルが刺さったwww
KernelのLVM周りで完全に応答がなくなるので、busterのKernelかLVM2が怪しいような気がする。
DRBDのSnapshotが不安定なら、zfsとかbtrfsのSnapshotで対応するしかないか。
使う時は、「/dev/drbd/by-res/testResource/0」もしくは、「/dev/drbd1000」だけど前者の方が分かり易そう。
実際に、マウントしたりして使用中になったら、こんな風に見える。
linstor resource list
lqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqk
x ResourceName x Node x Port x Usage x State x
tqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqu
x testResource x testvm x 7000 x InUse x UpToDate x
mqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqj
drbdadm status
testResource role:Primary
disk:UpToDate
NanoPC-T4
以前から気になっていて年明けにポチったNanoPC-T4が到着したので早速お試ししてみました。
到着した佐川というかDHLのビニールを破いた直後の梱包状態はこんな感じで中国から空輸されてきたものをそのまま佐川の伝票貼って送った感じ。
付属品は、本体、ヒートシンク、アクリル板の簡易ケース、ACアダプタ。
ACアダプタは、12V/2Aにしては小型だけど当然PSEマークはなし。
組み立てたらこんな感じ。横はスカスカなので、埃とかは入りまくりになりそう。
16GBのeMMCを内蔵しているので、armbianを書き込んだSDでbootしたあと、nand-sata-install.shを実行したら良い感じでeMMCに書き込んでくれて、後はSDカードなしでも起動可能。eMMCもそこそこ速い。
[email protected]:~# hdparm -t /dev/mmcblk1p1/dev/mmcblk1p1:
Timing buffered disk reads: 640 MB in 3.00 seconds = 212.99 MB/sec
早速、Bitzenyをマイニングしてみた結果は以下の通り
[2019-01-23 13:33:56] accepted: 1/1 (100.00%), 0.44 khash/s (yay!!!)
[2019-01-23 13:34:00] accepted: 2/2 (100.00%), 0.44 khash/s (yay!!!)
[2019-01-23 13:34:28] accepted: 3/3 (100.00%), 0.44 khash/s (yay!!!)
[2019-01-23 13:34:42] accepted: 4/4 (100.00%), 0.45 khash/s (yay!!!)
[2019-01-23 13:34:45] accepted: 5/5 (100.00%), 0.45 khash/s (yay!!!)
[2019-01-23 13:34:48] accepted: 6/6 (100.00%), 0.45 khash/s (yay!!!)
[2019-01-23 13:34:53] Stratum requested work restart
これみるとかなり優秀やん！！なんですが、2分後ぐらいにはCPU温度が88℃になって、0.32 khash/sまで低下。真冬のこの時期でもマイニングしたらヒートシンクじゃ追いついてない。
あとは、iperfの実行結果はめっちゃ優秀でほぼワイヤレート。USB接続とは大違い。
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 111 MBytes 934 Mbits/sec 174 209 KBytes
[ 5] 1.00-2.00 sec 109 MBytes 915 Mbits/sec 149 206 KBytes
[ 5] 2.00-3.00 sec 110 MBytes 926 Mbits/sec 92 208 KBytes
[ 5] 3.00-4.00 sec 110 MBytes 924 Mbits/sec 108 173 KBytes
[ 5] 4.00-5.00 sec 110 MBytes 925 Mbits/sec 141 162 KBytes
[ 5] 5.00-6.00 sec 110 MBytes 924 Mbits/sec 118 206 KBytes
[ 5] 6.00-7.00 sec 110 MBytes 924 Mbits/sec 111 208 KBytes
[ 5] 7.00-8.00 sec 110 MBytes 920 Mbits/sec 210 206 KBytes
[ 5] 8.00-9.00 sec 110 MBytes 924 Mbits/sec 196 206 KBytes
[ 5] 9.00-10.00 sec 110 MBytes 925 Mbits/sec 196 201 KBytes
– – – – – – – – – – – – – – – – – – – – – – – – –
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 1.08 GBytes 924 Mbits/sec 1495 sender
[ 5] 0.00-10.00 sec 1.07 GBytes 923 Mbits/sec receiver
ARMなおもちゃとしては1.8万円と割とお高いけど、冷却をちゃんとしたら価格に見合うだけの良い性能はありそう。マイニング以外にも面白い遊び方を考えねば。
色々復旧
ｇlusterfsのBrickを置いていたLVM thinpoolのMetadataが溢れた→glusterfsでsplitbrain発生→glusterfsのVolumeの整合性が怪しくなる→異常になったbrickを作り直し→ログが溢れたせいで/もパンク→redisやらmysqlやら色々停止。
自業自得とはいえもうやだ。。。