サーバー構成遍歴
検索して出てきても情報量 0 なポエム。
Fujitsu MX130 時代
Opteron 3260 に CPU を差し替えて使用していた。
開発用の VM を起動するのにしか使っていなかったのでそれほど面白いことはしてない。
面白いと言えば、ヒートシンクに金属製の洗濯ばさみを付けてた。これをするとチップセットが冷えて
ファンの回転数が下がるというおもしろい工夫だった。これをしたら本当に静かになって大変助かった。
そのまま、お仕事の事務所用 VM ホストとして現在も活躍中。小さいのはえらい。
あと、無駄に 8 コアに見える(4C8T)
Core i7 860 時代
2014 年ごろ。鼻毛鯖の CPU を交換してサーバーにしていた時代。
途中で CPU が Xeon X3450 に交換されている(が性能はまったく変わらないかむしろおちたくらい)
ケースが元々のケースで使用していたが HAF932 を貰った為、ケースだけ HAF932 に。
以降、電源が変更されたりして、徐々に元の部品がなくなっていった。
動作させていた機能
- Chinachu
- ファイルサーバー
構成
Hypervisor: ESXi
ストレージ: WD RED 2TB * 3 (途中で 3TB * 3 に変更)
起動は USB から行っていた記憶。
メモリも 16GB 程度だったので VM は数台だったと思う。
ハイパーバイザーを Xen Server とか Proxmox VE とか Windows Server(hyper-v)に変更して色々実験していた。
RAID カード沼
いろいろな RAID カードを買っては試した。感想は以下。
- Dell Perc 6i
割と普通に動いたけど、確かピンのマスクが必要だった記憶。
ESXi でもちゃんとドライバが当たった…はず。
<a href="http://yannickdekoeijer.blogspot.com/2012/04/modding-dell-perc-6-sas-raidcontroller.html">http://yannickdekoeijer.blogspot.com/2012/04/modding-dell-perc-6-sas-raidcontroller.html
- HP Smart Array P410
ESXi だと、HP のサーバーじゃないとドライバが入らない。Windows Server だと普通に動く。なので Windows Server の時使ってた。
これもピンをマスクしたような…。 RAID カード全般にそうだけど、差すと起動がとても遅くなるのつらい。
バッテリーがついてなかったので、ライトバックができなくてつらかった。
- NEC N8103-117 (LSI 8708EM2)
バッテリつき。割と良かった。 よかったが、3TB の HDD に対応しておらず、残念ながら退役させた。
- まとめ
ESXi だと割と状態の監視が厳しい(と言っても OK か DEGRADE かくらいは分かる)。Windows Server だとその辺はさすがに完備。
でも、色々と ESXi は便利だった…
Core i5 4570 時代
いわゆる自作機。Core i7 はコスパ悪いので基本的には選ばない。のお気持ち。
動作させていた VM
- Chinachu
- ファイルサーバー
- fastladder
- Mastodon
ESXi
前からの構成とほぼ同じ。 RAID カードは確か Perc6i だった記憶。
安定 of 安定。特に変更する必要はなかったが、やっぱり Hypervisor の入替はやっていた模様。
結局 ESXi に戻るみたいな。多分このサーバーから Mastodon の運用始めてるはず。
Ryzen 7 1700 時代 (現行)
買う時、かなりの博打で買った構成。というのも、当時の Ryzen はメモリとの相性がキツくて、
動くか動かないかわからない。推奨のメモリは、マザボメーカーの動作確認済みメモリだけ。
みたいな状態。
- Ryzen 1700
- ASRock X370 Gaming K4 (Intel NIC が乗っているから選んだものの Windows Server のドライバがない。という罠)
- Corsair Vengeance LPX 16GB * 2
Windows Server 2019 第一期
ESXi を使いたかったが、Ryzen だと PCI パススルーが上手く行かなかったため、諦めて Windows Server で組む羽目になった。
全ての VM が機能毎に一個ずつ存在する構成。
VM たち
Chinachu
これが問題で Windows Server になった。今までは PT3 をパススルーしていたが、それが不可能になったので
ホスト側で Mirakurun を動かし、そこに接続する形で構成した。安定して動いているのでまぁ良い。
Mastodon
本番インスタンスとテストインスタンスがそれぞれ別 VM。Non docker で立てていた。
また、PostgreSQL を独立した VM として切り出して、そこに依存することでさらに加速させた。
Minio
minio 専用 VM を立てていた。
fastladder
最初は non-docker だったが、docker にした。昔から mysql で構成していたのでそのまま。
zabbix
mysql と組み合わせて作っていた。監視対象が同一 PC 内にいるってどうなのよ?という問題があったので、
Raspberry Pi (microSD カード運用)→(壊れたので SSD 運用)→(性能不足?)→Jetson Nano
→(Jetson を zabbix に使うのダメでしょ)→Raspberry Pi(64bit, postgresql)
と、さすらっている。
ElasticSearch
ログ解析というのをやりたくて導入。これが兎にも角にもメモリ食いで、色々と悲劇を生んだ。
elasticsearch + Logstash + Kibana というお約束構成だった、全部を同一 VM に入れた為に
メモリ量が 4GB でも足りないという状態になり、大変つらかった。
ストレージ
Adaptec 6805T + BBWC を購入して、RAID10 を構成していた。WD RED でも、ストライピングすると
割と早いのでとても良かった。
Windows Server 2019 第二期 docker
この頃は、docker が正直言って本番環境に投入するものではないと思っていた。理由は不安定だから。
CentOS5 に docker を入れて、Web アプリを動かしたら 12 日でカーネルパニックした苦い思い出がある。
※ CentOS5 のカーネルが古すぎただけだと思う。Ubuntu16.04LTS にしたら安定したので。
※ この時以来、サーバーは Ubuntu で構成するようになった。
この時期、SSD を買いまくった記憶がある。サービス動かすのに容量より球数が欲しくて、
兎にも角にも毎月のように SSD を投入したような。(4 台まで増えました)
VM たち
基本的に VM は同じだが、全ての VM を docker 化した。
最初は、Mastodon のバージョンアップ時にサービスが停止する時間がながいのが嫌だったんだけれども、
※ assets:precompile がメモリを食いまくる&長いのでその間サービスを停止していた。
docker 化してイメージを作ってしまえば、そこの入替と db:migrate だけでバージョンが上げられるので
大変楽になった。この時期から、Mastodon は自動的に Master 追従するようになった。
そして、docker のイメージをビルドする為のサーバーが VM として追加された。
この時点で、メモリがかなり逼迫しており、30GB/32GB くらい常時使用しているような状態だった。
VM をシャットダウンするとメモリ不足で起動できないとか、サーバーで Firefox 起動しっぱなしだと
スワップ始まっちゃうとか、本当にギリギリだった。
docker swarm を入れて上手いことやればもっとリソースを詰めることができた(検討はした)
が、ストレージが大げさになって面倒だなぁ。ということでやらなかった。
Windows Server 2019 第三期 kubernetes
kubernetes を入れれば、docker コンテナの管理が楽になって、システムリソースが有効に使える。
しかも、ナウでトレンディ。将来の為にもこれはやっておくべきだろう。ということで構成変更。
この時、財団は ThinkCentre Tiny M73p で臨時にホストしていた。Hyper-V でよかったー
と思った瞬間ではある。
で、当然メモリが足りないのでついに増設を決意した。 このマザーボード、メモリを増やすと
速度が落ちるという仕様で、しかも動くかどうか博打だったが、なぜか XMP を有効にするとメモリが
動作して、速度も早いまま。それ以外では動かないというワケの分からない状態で動いている。
VM
docker イメージビルド
kubernetes 内で kaniko を使ってビルドしても良かったが、(テストして動くことは確認した)
唐突にワーカーノードに負荷がかかるのは嬉しくないので独立させている。
Chinachu
これは他にあんまり依存してほしくないので独立した VM としている
kubernetes
VM の構成は、kubernetes master / worker * 3
kubernetes master は 2core / 2GB RAM
worker は 4core / 8GB RAM
バージョンは最新を追いかけている。 kubeadm によるセットアップ。
ストレージ
NFS
NFS のできるだけ新しい実装が欲しかったのと、使ってみたかったので、Arch Linux で構築していた。
問題なく動作していたが、あまりに普通であるが故に色々といじられる対象となる
GlusterFS(失敗、切り戻し)
GlusterFS on kubernetes で構築してみた。
<a href="https://qiita.com/yakumo/items/3562be29084ca09018d3">https://qiita.com/yakumo/items/3562be29084ca09018d3
しかし、SSD で組んだにもかかわらず速度的に 30MB/s 程度しか出せず、メリットと速度を天秤にかけた結果切り戻しに。
動作自体はちゃんと動いていたので問題はなさそうだが、次に試すなら Ceph にすると思う。
(Ceph にすれば Minio も廃止できるので)
ダイナミックボリューム(RAID-5、失敗)
元々は RAID カードがトラブったのが嫌になってしまい、SATA オンリーに切り替えた。
その際、ポート数が足りない為、HDD4 台 →3 台になってしまって RAID1 で 2 台、素が 1 台という納得いかない
構成で使っていた。結果、RAID1 側の空き容量が偏って減ってしまいちょっと嫌だなという状態に。
なので、RAID5(パリティあるの本当はあんまりうれしくないが)を構成しようとして、
Windows Server の機能の RAID-5 を組んでみた。…結果、書込速度が 35MB/s 程度になってしまいなんだかなぁ…
ググってみると記憶域スペースならもっと早いらしい。ということで移行断念した。
記憶域スペース (parity、RAID-5 相当、失敗)
まず最初に、サーバーマネージャから構成しようとすると Parity が構成できない。
powershell を使って構成したら上手く構成できた…が。
データのコピー中に Windows Update で再起動がかかったのか、翌朝起きてみたら
ディスクがオフラインになっていた。
…正直、これを使い続けるのは怖いので撤退。移行は失敗とした。
FreeNAS
2019/10/20 導入。 ZFS は以前に導入していた時期があり、信頼はできるのでもうこれでいこうと導入。
Hyper-V にも RDM(Raw Device Mapping) があることをしり、HDD 3 台を全部任せることに。
ZFS はさすがに普通に動いてくれたので大変助かった。
そして、FreeNAS で NFS が使えるので SSD も FreeNAS に任せて、NFS サーバーを停止したのであった。
内部ネットワーク
flannel、MetalLB を使用している。
外部ネットワーク
RTX 期
RTX1200 を使用。 LAN1 が家庭用セグメント、LAN2 が WAN、LAN3 がサーバーセグメントという使い分けをしていた。
これは、RTX1000 とか 1100 の時代からの config を引き継いで使っていた。LAN1 -> LAN3 は NAT で接続する形。
歴代の RTX を使ってきてホント不満がなかった。RTX1200 の筐体がいっきに大きくなったのは正直つらい。
その他、EdgeRouter Lite 3 を試したり、OpenWRT を試したりしてる。
VyOS 期 (2019/10/27)
RTX1200 が大きすぎて置き場所に困ったのと、サーバーの LAN ポートを 1 ポート開放(ドライバ入れてなかった)
に伴い、RTX1200 を無くしてもいけるなという気分で変更された。実利的には、OpenVPN の終端を行う VM が
1core 512MB で構築されていて、その VM の割り当て分を VyOS に変えることで実質無料みたいな状態で処理できている。
LAN の構成そのものは変わっておらず、 zone は internet, intra , server と cloud の 4 つにしてある。
OpenVPN の終端がルーターに移動したので、OpenVPN の先にいるフロントも統合的に扱えるようになって
むしろスッキリした感じである。
Mastodon 上での助言で、intra->server の NAT はやめて、ファイヤウォールによるアクセス制御に変更した。
速度的には、RTX1200 より向上したように思えるが、速度的にはほぼ変わっていない(VDSL なので 100Mbps 上限)
OpenWRT 期(2019/10/29)
VyOS 期が短いように思えるが、 tootctl domains crawl
を実行するとネットワークが不安定(外部接続不可)
になるというトラブルが発生してどうにかしようとして置き換えたもの。
実はこのトラブルが DS-Lite 起因ではないかという疑惑があり、無駄な置き換えだったかもしれない。
ある意味、GUI で設定できて楽と言えば楽。OpenVPN は GUI より設定ファイルいじった方が早い気もするが…
WSR-1166DHP を使用しているが(無線 LAN は無効)、CPU 使用率が意外と高いのでもう少し良いルーターが必要かもしれない。
Discussion