muninでMariaDB10.0.4を監視してたら、
情報がほとんどあつまっていなかった。
munin自体はepelからインストールしたのだが、
これに内包されている「mysql_」プラグインはMySQL5.1レベルのものまでしかサポートしていないため、
以下にあるファイルで上書きする必要がある。
このファイルで上書き、
1行目の
#!@@PERL@@
を
#!/usr/bin/perl
に直したら、MariaDB10.0.4でも問題なく動いた。
以上
remiレポジトリからインストールしたredis3.2でredis-cliを使うと、
コマンドアシスト（ヒント）が効くようだ。
たとえば、zrevrageを打ちたいとき、
zとうつと、アシストが出て、タブ押下で補完できる。
redisのコマンドって、なかなか覚えられないと思うが、
アシストがあると覚えやすくていいと思う。
以上
monitというとプロセス監視をしてくれるだけのイメージがあったが、
深く触ってみると、こいつはすごいなと思った。
基本的にmonitあれば大半のことは事足りると思う。
ちなみに環境は、centos7で、monitはepelレポジトリからインストールしました。
monitの便利なところとして、以下があげられる。
- プロセスの死活監視（ダウンしてくれれば、勝手に起動してくれるし、勝手に起動しない形も可能。DBなんかは勝手に起動して問題あるケースもあるよね？）
- 閾値と発砲の関連付け
- SMTPを使った発砲機能（リトライ機能もある）
- web管理画面
さらに、m/monitをつかえば、情報の集約も可能となる。
（有料だけど、買い切りでそれほど高くないのは、良心的）
クラウド環境では、かなりの監視ツールがあるが、
こねたことはできないので（できても意外に金がかかる。。）、
monit（もしくはm/monit）を併用すると、結構安心して夜も眠れる環境が出来そう。
どこかで、monitの設定を書いてみようと思う。
以上
ansibleのベストプラクティスを理解するのに時間がかかったが、
実案件の構築を通して、なんとなくわかってきた。
個人的な所感を表現すると、
「環境・特性・筐体ごとに役割を分割し、変数を割り当てる」
ということになる。
言葉で表すと、若干意味不明なので、例を書いてみる。
＜例＞
あるWEBサイトを作る場合、
サービス側と管理側でシステムが分かれるケースが多いだろう。
その場合、サービス側ではアクセスが多く、
参照が多いのであれば、DBに加えて、様々なキャッシュも併用する。
同時にwebサーバではkeepaliveを強くしたり、画像のキャッシュを行うこともあるだろう。
反対に、管理側では、アクセス人数が限られていることもあり、
キャッシュは使わないし、正確なデータ提供が求められる。
＜サービス側の構成＞
例えば、
- webサーバ2台 → apache,phpが必要
- cacheサーバ2台 → memcachedが必要
- dbサーバ2台（master、slave） → mysqlが必要
というようなケースを考えてみよう。
そして、
- 本番環境（production）
- 確認環境（staging）
- テスト環境（test）
という環境があるとする。
という状況において、
本番のインベントリファイルは以下のようになる。
inventry-service-production.ini
# ---------- # servers # ---------- [servers-service-web] service-production-web01 service-production-web02 ### ↑のセクションは、webサーバとしてのグルーピング [servers-service-cache] service-production-cache01 service-production-cache02 ### ↑のセクションは、cacheサーバとしてのグルーピング [servers-service-db] service-production-db01 service-production-db02 ### ↑のセクションは、dbサーバとしてのグルーピング # ---------- # grouping # ---------- [servers-service:children] servers-service-web servers-service-cache servers-service-db ### ↑のセクションは、全体のグルーピング # ---------- # environment # ---------- [env-service-production:children] servers-service-web servers-service-cache servers-service-db ### ↑のセクションは、本番環境全体のグルーピング [env-service-production-web:childeren] servers-service-web ### ↑のセクションは、本番環境webサーバのグルーピング [env-service-production-cache:childeren] servers-service-cache ### ↑のセクションは、本番環境cacheサーバのグルーピング [env-service-production-db:childeren] servers-service-db ### ↑のセクションは、本番環境dbサーバとしてのグルーピング
この状態において、
必要なgroup_vars以下のファイルは以下の通りとなる。
- servers-service.yml
- env-service-production.yml
- env-service-production-web.yml
- env-service-production-cache.yml
- env-service-production-db.yml
1のファイルに書かれる設定は、「サービス側共通設定」である。
つまり、環境や種別が変わっても、必ず設定されるべきものである。
例えば、sshの設定などは、比較的このケースにあたるだろう。
（当然、all.ymlでもよい。ただし、all.ymlは、サービス側・管理側での共通設定という位置づけの方がよいと思う）
2のファイルに書かれる設定は、「本番環境サービス側共通設定」である。
つまり、本番環境のすべての筐体に設定されるべきものである。
例えば、本番環境のみ監視ツールを入れたい場合などのは、このケースにあたるだろう。
3のファイルに書かれる設定は、「本番環境のサービス側webサーバでの共通設定」である。
ここでは、apacheやphpの設定がそれにあたる。
どうように、4、5も解釈できるだろう。
さらにいうと、dbサーバでは、masterとslaveがわかれるが、
これはhost_varsを使って、さらに筐体ごとに設定をわけてやればよい。
ansibleは奥が深い。
設定された変数の適用順番、マージ方法、上書き、予約語（関数）衝突もあり、
なかなかうまくいかないだろうが、
このあたりを抑えておくと、幅が広がる感じがすると思う。
管理側については、
省略するが、大筋この流れでかけるはず。
以上
ansibleでshellコマンドを使うとき、
リスト変数に対してできるだけ簡単にできないかをやってみた。
以下備忘録です。
[ シナリオ ]
複数ユーザのbashrcに同じ情報（ここではumask）を書き込む
[ コード ]
- name: change umask
shell: dummy=`sudo cat /home/{{ item }}/.bashrc | grep -F "umask"` && [[ -n $dummy ]] || echo "umask 002" >> /home/{{ item }}/.bashrc && source /home/{{ item }}/.bashrc
with_items:
- hoge
- fuga
failed_when: false
tags: common, users
ちょっと長いが、.bashrcからumaskをgrepして、
結果がなければ、umaskを書き込んで、
sourceで反映している。
本来ならregisterとか使ってやるべきだが、
リスト変数に対して書くと冗長になるので、
このようなやり方にした。
Dict型でregisterできればよいのだけど、
そんな方法あるのかな？
set_factとかでもやれそうな気がするんだけど、
一時的な変数をあまり維持するのも微妙だしな。。
GCPとAWSで、拠点（リージョン）間の通信速度を簡単に図ってみた。
正確ではないし、3回程度しか実施していないので、その点は考慮ください。
■ComputerEngineのインスタンス（ASIA）から（AMERICA東部）への２３０MBのSCP
24秒
■EC2のインスタンス（TOKYO）から（AMERICA東部）への２３０MBのSCP
23秒
ほとんど同じ。
GCPはネットワークの強さをうたっているが、AWSと変わらないケースもある。
GCPの場合、ローカルネットワーク上で、異なるリージョンのインスタンスをまとめられるので、
データベースなどを複数リージョンで準同期レプリケーションできるとよいと思っていたが、
その目論見は成立しそうにないことがわかった。
ただし、GCPはグローバルロードバランサーとか、CloudStorageがめちゃくちゃ優秀だから、
実際にサービスとしてユーザの体感速度的なものは、広域範囲で考えればAWSより優秀なのではないか。
GCP（Google Cloud Platform）における、
Google Cloud Storage（以下、GCS）がすごい。
AWSでいうところのS3にあたるものですが、
バケット間同期が、
25,000ファイル、8GBを転送（同期）するのに、約5分。
驚異的。。
JAVAの並列処理（４CORE）で、
S3に同じ量をアップするのに、8分だったから、
ちょっと負けた気分。
なお、GCSはgsutilというツールを使うのがよい。
JAVAなどはSDKが出ているが、とてもめんどくさい。
gsutilは、gcloudの認証に影響を受けるようなので、
予めサービスアカウントを発行して、gcloudでの認証処理をしておくのがよい。
追記
ちなみに、上記の5分という数字は、
バケットのリージョンが異なっていても、同じでも変わらない。
つまり、AsiaからAmericaのバケット間転送でも超高速。
驚異的。。。
以前の記事で、
master、slave構成において、
- 非同期レプリケーション
- 準同期レプリケーション
があることが抜けていた。
今回のように、maxscaleでsalve auto promotionを使う場合、
データロスト率が低い準同期方式がよいと思われる。
準同期レプリケーションについては、詳細説明をされているホームページがあるので、
それを参照されたい。
準同期レプリケーションの設定は以下。
[mysqld] plugin-load=rpl_semi_sync_master=semisync_master.so;rpl_semi_sync_slave=semisync_slave.so rpl_semi_sync_master_enabled=1 rpl_semi_sync_master_timeout=1000 rpl_semi_sync_slave_enabled=1
これで、プラグインのロードと、
準同期レプリケーションの設定が入る。
なお、ここでは、masterがslaveに、slaveがmasterになることがあるので、
master・slave問わず同じ設定を入れている。
ここで準同期レプリケーションの課題を考えてみると、以下のようなものがありそうだ。
- ネットワーク帯域が狭いとクラスターのパフォーマンスに影響を及ぼす
- slave台数が増えるとクラスターのパフォーマンスに影響を及ぼす
- バイナリログサイズがでかいとクラスターのパフォーマンスに影響を及ぼす
非同期と混在させることが出来なかったような気がするので、
遠隔地にバックアップをおくこともできないと思われる。
これらについて、検証したら詳細を記述したい。
前回、
Slave auto promotionについて記載するといったが、
詳細はさておき、先に結論を書いておく。
【前提】
- maxscaleによるWriterReaderSplit機能を使う
- masterダウン時には、生きているslaveが自動昇格する
【結論】
- ノード数は3以上が推奨と書かれているが、ノード数が1になると、maxscaleのWriterReaderSplitが機能しなくなる
- slaveの同期が失敗していている状態では、masterに昇格しないし、maxscaleのクラスターからも外れる
ということが挙げられる。
つまり、3ノードあっても、2ノード死んだら、実質アウトなのである。
そのため、打っておく手段としては、
- masterがダウン→手動復旧→自動で新masterのslaveとなるようにする
- 1ノードになった場合、maxscale経由でアクセスしないようにする
ということをやっておけば完璧だと思われる。
ちなみに、良い点として、masterがダウン→復旧しても、新masterとバイナリログポジションがずれているため、
maxsacle上のクラスターからは外され、マルチマスター状態にはならない。（単独のマスターとして存在する）
幸い、maxscaleは結構イベントが拾えるので、
上記対策もなんとか実現できそうな気がしている。
そのあたりの検証記事を、今後書こうと思います。
以上
MariaDBでクラスターを組む際、
- maxscale
- mariadb-replication-manager
- MariaDB
を使うとよい。
そもそも、MariaDBのクラスターには、
- Spider（マルチマスター、データ分散型）
- Galera（マルチマスター、データ同期型）
- Slave auto promotion（マスタースレーブ、データ同期型）
のような3つの手段があるが（もっとあるかも。。調べてません。）、
GaleraとSlave auto promotionであれば、maxslace & repliacation-managerの監視および発砲でいける。
すいません、Spliderは記載しておきながら、大してわからないので、
GaleraとSlave auto promotionの特徴を書いてみる。
【Galera】
（メリット）
- 全てmasterであるため、障害時のダウンタイムがほぼ0
- 各ノードのデータ状況に差異が出にくい
（デメリット）
- データの同期化のため、ノード数が増えると更新時間がかかる
- テーブルor行ロックは同一ノードのみ有効
【Slave auto promotion】
（メリット）
- データ更新時間はシングル構成と変わらない（うそ、シングルより遅いし、レプリケーションタイプにも影響をうける）
（デメリット）
- Slaveの昇格が完了するまではダウンタイムとなる
- Slave遅延が発生するとデータのロストが発生する
上記のような特徴があるので、
使いどころはサービスに依存するのかもしれない。
私の見解では、
・同一データを更新することがない場合 → Galera
・同一データを更新することが多い場合 → Slave auto promotion
がよいと思う。
決め手は、更新速度とロックの有無かと。
※Spiderは分散データなので、Slave auto promotionと組み合わせないとデータロストしちゃうかも。。
Galeraは結構やっている人がいるから、
Slave auto promotionについて、
maxscaleとreplication-managerを用いた構成の説明（やってみた）を近々で書こうと思う。
以上