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でもちゃんとドライバが当たった…はず。
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アプリを動かしたら1〜2日でカーネルパニックした苦い思い出がある。
※ 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で構築してみた。
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使用率が意外と高いのでもう少し良いルーターが必要かもしれない。