DigiLoog

続きを読む »

• システム構成

そんな事もあり、出来上がった現環境の負荷分散型データベースがこちら。
構成をシンプルにしたかった事もあり、フロントエンドはmaxscaleを用いてクエリ分散をしつつ、
maxscale自体はkeepalived(VRRP)でL3冗長化をしてみた。
実際にクエリを捌くバックエンドDBには、MariaDBを採用しつつGTIDレプリケーションをしてみた。
ちなみに、第2案としてMariaDB Galera Clusterを用いたクラスタリングも検討したが、
構成が複雑になる上、奇数台数でクラスタを組まないと障害時にスプリットブレインが発生するので没にした。

このシステム構成を取ると、writeクエリが1箇所に集中するのが課題だが、
書き込み対象が集中する事によって、クラスタ構成時に必要なトランザクションロックを考えなくて良いのと、
一番やりたかった読込み処理の負荷分散が出来る上、
DB本体がクエリを捌けなくなったらスケールアウトが楽に出来るので採用した。

ロードバランサ・リバースプロキシとして使い慣れている、HAProxyを用いた構成を検討した時期もあったのだが、
データベースのmaster停止時、slaveをmasterに昇格する作業が面倒だったのと、
HAProxyとmaxscaleの処理速度を比較した際に、maxscaleに軍配が上がったのでHAProxy案は没にした。

………

• システム障害動作

全体の基本設計はActive/Standbyを採用し、それぞれ対となるサーバ・アプリで切り替わる様にしてある。
ただし、ステートフルインスペクションは実装していないので、待機系に移った時はセッション断が発生する。
大多数のアプリケーションなら、セッションを張り直したりして瞬断が発生しても上手く動作する事が多いが、
zabbixはDBセッションを維持し続ける事を前提に設計してある為、
正常系が倒れて待機系に切り替わるとDB書き込みが滞留した後、プロセスがクラッシュして停止する欠点がある。
これはオフィシャルでも議論が続いており、解決策は「zabbixのログを監視してDB断を検知したら再起動」となる。

zabbixの様な特殊ケースは置いて、基本設計はプロセス停止後1～3秒で待機系に切り替わる様に設定した。
サーバメンテナンスの時、意図的にフェールオーバー・フェールバックを発生させてみたが、
設計通りにシステム切り替えと、昇格・降格処理を行う事が出来た。

ちなみに、maxscaleが倒れた時はMariaDBへのヘルスモニタも停止するが、
MariaDBが倒れた時はmaxscaleからのヘルスモニタが来続けており、
MariaDB復活直後から2～4秒ほど正常性確認をした上でクエリが振り直される様にしてある。

master障害後に自動復旧させるか否かは設計する人の考えで変わってくるが、
今回は自鯖環境な上、データの整合性が崩れてもバックアップからリストアさせる事が許容出来るので、
負荷分散に再追加するように設定してある。
ただ、master/slaveの昇格・降格については自動で復旧しないようにした。
これは、出来る限りレプリケーション方向を変更したく無い為の設計方針となっている。

………

• 待機系切り離し

正常稼働時に待機系が倒れた時についても、システム切り離しを自動で行い、
復旧時は自動的に負荷分散に追加する様にしてある。

この設計にしておく事で、メンテナンス時に待機系から手を加える事が出来るのと、
ミスが発生した時も正常系を元に復元する事が出来るのがメリットとなる。

………

自鯖刷新で特に力を入れたのが、ロードバランサ・データベースの連携部分だった事もあり、
システム設計・構築作業・動作検証に時間を要したが、課題を払拭する事が出来たので良かった。
maxscaleを用いたデータベース負荷分散手法は、Amazon RDSを利用する場合にも応用出来るので、
自鯖で慣れておく事で、本業にも役立てる事が出来る。
VRRPを用いたフロントエンド冗長化を行った都合上、各サーバを同一セグメントで立てる必要があったが、
グローバルロードバランサと、遠隔レプリケーションを使えば拠点レベルでの冗長化も出来る様になる。

稼働してから日が浅い為、実データも数ギガしか無いが、それなりに成長しだしたデータベースなので、
スキルを修得しながら今後も自鯖で遊んでいこうと思う。

« 続きを隠す

続きを読む »

• 刷新理由

自宅サーバを刷新した主な理由は3つ。
『ハードウェア機器の保守切れ』『室温上昇に伴う冷房費抑制』『拠点間VPN基盤見直し』だった。

ハードウェアについては自作PCだったので組み直せば良いのだが、
KVM管理に開発停止済のアプリを使っていた為、単純に組み直すのでは無く刷新レベルの作業が必要だった。
また、室温については気温も考慮すると冷房必須のゾーンになっていた。
顕著になったのが2018年～2019年の猛暑で、室温を下げる為に冷房をガンガン付けたら電気代が跳ね上がった。
VPN基盤については、従来から借りているVPSと自鯖間でシステム連携する為にVPNを構築してあった。
ただ、VPNがIKEv1を元に構築してある事と、リフレッシュの為に数時間でプロセス再起動をしていた為、
メンテ中にプロセス再起動が走り、データが吹っ飛ぶのを改善したかった。

………

• 構成検討

『やはり、物理サーバ触りたい…』という事もあり、当初はNWラック(クアッド)を借りようと計画していた。
ただ、昨年旧サーバでディスク障害が頻発して物理作業とHDD出費が重なった。
この時思ったのが、自宅ならば簡単にディスク交換可能だが、
NWラックを借りると物理的にデータセンターへ駆け込む必要が出てくる為、
自宅サーバの代わりとして使うにはデメリットが多くなりそうだった。

そんな事もあり、第2案として浮上していた専用サーバを借用する方針に転換。
様々なサーバ事業者から見積もりを取って比較した所、
サーバスペック・グローバルIP・運用体制でメリットが大きかった、
「さくらの専用サーバ」で専用サーバ2機を借りる事にした。
とは言っても、自宅サーバを完全撤去するのも悲しいので、
消費電力が低く、発熱も少なめなベアボーンを使って小規模なHyper-Vホストを自宅運用する事にした。

………

• 構成図

メインサーバが「さくらの専用サーバ」に移った事もあり、
自宅とメインサーバ間で通信量が増えそうだったので、専用仮想ルータを用いた拠点間VPNにした。
VPN内のルーティングはeBGPを使い、拠点単位のプライベートIPを経路交換している。

他にも録画サーバ・ラズパイ・ディスク装置もあるが、バックボーンと少し違う立ち位置なので構成図は割愛
個人所有を考えるとやり過ぎ感が凄まじいが、自鯖で修得した技術を元に飯を食べているので必要経費という事で。

サーバは基本的に拠点内で両アクティブ構成となっており、ロードバランサ等を用いて負荷分散している。
ただ、N+1を構築する程の資金が無いので、メンテでシステム停止する時は、
ロードバランサ・リバースプロキシ・VRRP冗長化を用いたフェールオーバーで縮退稼働する様に設計した。
VPN網はシングル構成となっているが、
グローバルIP直通信用にプロバイダとPPPoEセッションプラスが必要なので、諦めてアクティブのみで行く事にした。
この構成で問題が出てきたら、CiscoASAを使ってスタンバイ用VPN中継点を作ろうと思う。

………

• NW設備

物理サーバを遠隔地レンタルした事もあり、主要のNW装置を仮想化する必要があった。
その為、今回からソフトウェアルータを採用して、仮想サーバ環境上で動かす事にした。

仮想サーバからインターネットに抜ける箇所は大容量が流れるので、
ベンダーサポートもあるIIJ SEILを使ってNAT変換・トラフィック転送を行う事にした。
バックボーンを支える拠点間VPNにはVyOSを採用し、将来IPv6をBGPで喋らせる時にも対応出来る様にした。
両ルータとも初の試みかつ、今まで触った事の無い機器だったので慣れる迄に時間が必要だったが、
100Mbps級のトラフィックを流しても安定稼働しているので満足いく結果になった。

………

この記事を公開しているブログも既に新環境で稼働しており、それなりのアクセス数を捌いている。
その為、バックエンドのデータベースに相応のスペックが必要となるのだが、
今までの知見をフルに使ってチューニングした結果、DBサーバ2台で負荷分散出来ている。
ちなみに、今までは各サーバにデータベースを同梱する構成にしていたが、
今回からはmaxscaleを用いて負荷分散しつつ、データベース専用サーバを用意する方針に変更した。

気がかりな事としては、今回の刷新でサーバのメイン機能が自宅外になってしまった為、
「自宅サーバ」と言うと微妙な所。
とは言っても、Hyper-Vホストは自宅で絶賛稼働中な上、
後は気持ちの問題だと思うので今後も自宅サーバ環境を名乗ろうと思う。

ともあれ、数年越しの “nowsky system-lab BB/ns-lab BB” 刷新計画が、予定通り4月末で完了した。
そうは言っても技術調査が終わっておらずPrometheusが未構築だったり、
新しいスキル領域として、ActiveDirectoryも本稼働させたいので自鯖ver3.0になってもやる事は目白押し。
色々とやりたい事は溜まっているが、暫くの間は刷新後の自宅サーバ環境をブログで紹介していこうと思う。

« 続きを隠す