tech zabbix ( nginx + php-fpm + MariaDB ) 導入 自宅とIDCFクラウド環境のopenvpnによるLAN to LAN接続が成功したので、ようやく監視環境を構築する。nagiosを割と使い込んでいたんだけど、サービス監視とリソースウォッチが統合されているzabbixを使ってみたかった。データもRDBに貯められるので冗長構成を作り易い。いまいちだったら別のものを作るという考えで、とりあえず使い始めてみる。インストールはもはや何の問題にもならない。zabbixリポジトリを設定してyum installするだけ。依存関係を解決する形でphpやhttpdもインストールされる。DBサーバには別サーバdb1のMariaDBを使うので構築済みの前提で進める。 yum install http://repo.zabbix.com/zabbix/3.2/rhel/7/x86_64/zabbix-java-gateway-3.2.3-1.el7.x86_64.rpm yum install zabbix-server-mysql zabbix-web-mysql zabbix-web-japanese zabbix-agent scp /usr/sh
tech MariaDB Galera Cluster の Split-Brain 問題 MySQLのマスター・スレーブ構成からMariaDBのマルチマスター構成に移行してから、DB側の運用は非常に楽になった。wordpressに関して言えばWeb+DBのセットが2つあるので、その単位でラウンドロビンしている限り、まったく問題なく複数台構成を取れる(Webの接続先DBがlocalhostという状態)。しかし、DBのみを分離してreadもwriteも関係なくラウンドロビンさせると、どうしてもdead lockが頻発してしまって不都合が起きやすい。 結局マルチマスターにもかかわらず、このdead lock問題のために、writeが混ざる場合は片側のDBに寄せるしかなくなってしまう。性能面では恩恵の低いマルチマスターだが、それでも単にトラフィックを切り替えるだけでフェールオーバできるのだから運用面でのシンプルさは評価できる。期待通りという訳ではないが、以前よりは使いやすいので、このまま運用してみようと思う。Webとセットで分散させれば問題起きにくいし。 そして、もう1つの問題がSprit-Brain。GlusterFSもそうだけど、マルチマスター構成のデータモデルには常に
tech IDCFクラウド openvpn による LAN to LAN 接続 IDCFクラウドで不意の障害に見舞われることが増え始めたので、もう少しまともな運用を考える。たまたま自分でアクセスしたときに障害に気付くような状況をまずは改善する。IDCFクラウドのリソースはケチケチで運用しているので、自宅のサーバからクラウド側のサーバを監視するのが理想的。できればウェブ系の監視だけでなく、サーバごとのリソースウォッチも行いたいので、自宅から個々のサーバ、あるいはそのサーバ内のコンテナにアクセスできるように設定したい。そこでVPNの導入を検討してみる。 VPN接続は以前GMOクラウドでも利用していたが、そのときはクラウド側のサーバ1台ごとに自宅のLANに接続させていた。このVPN経路を使って自宅のchef serverからクラウド側のサーバをセットアップしていたんだけど、GMOクラウドはサーバごとに1つのGIPをもらえたので、この構造で困ることはなかった。今はchef serverからchef zeroに切り替えたとはいえ、クラウド側のサーバやコンテナを全て自宅のchef zeroからセットアップするので、クラウド側から自宅のchef zeroコンテナが見える必要
tech IDCFクラウド wordpress 障害対応 今までVPSやGMOクラウド時代に、wordpress運用で障害らしい障害は起こしたことなかった。サーバ運用が硬直的だったので大きな変更を行えなかったというのも理由の1つではあるが。IDCFクラウドへの移行後は、vmwareノード上にlxcコンテナを作成して、そのコンテナ上でwordpressを運用している。更にwordpressのphp部分はGlusterFSで、データ部分はMariaDBで2台を同期している。これだけ構成を複雑化させてしまったせいかもしれないが、遂にwebサーバにて予期しない障害が発生した。 1つ目はlxcコンテナを使ったが故の障害。症状だけで言えば、wordpressを動かすための php-fpmプロセスが死んでしまっていた。ログインしても動作が不安定なので、とりあえず再起動する。この時期はまだホストOSの仮想ブリッジ問題を調査する前だったので、サーバ再起動によってコンテナが外部と通信できなくなってしまい、その回復を待つ間も障害が続く形となってしまった。このときは、とにかくいろいろなコマンドを打ってコンテナが仮想ブリッジ経由で外と繋がりだしたところでサービス復
product Seagate Archive Disk 8TB ST8000AS0002 レビュー ここ数年、スケールアウトで逃げ続けたディスク容量問題。中心的に使ってきた3TBと昨今のSATAディスク最大容量との乖離も大きくなってきたので、いい加減8TBにスケールアップを行った。SeagateのアーカイブディスクST8000AS0002という製品。大きなファイル用途とのことで、OS領域などには向かないらしい。このディスクを迎えるに当たって、予めGlusterFS上にある細かいファイルはアーカイブして固めておいたので、普段使いで違和感を覚えたことはない。特にストレスを感じることもなく、GlusterFSの1ブリックとして立派に働いてくれている。 SeagateST8000AS0002 バルク品 (ハードディスク/3.5インチ/8TB/SATA) 価格：28400円（税込、送料無料) (2016/11/11時点) この8TBディスクの投入によって、GlusterFSのブリックは1ノード当たり8TBと3TB3本といびつな構成になってしまった。これでdistributedな構成を取っており、同じ構成のもう１ノードとmirrorを組んでいる。2台目に8T
tech IDCFクラウド wordpress 複数台構成 構築 wordpressの運用は既に8年近くに渡っているが、まともな複数台運用が実現できていなかった。大したコンテンツではないが、それでもクラウド費用くらいは稼いでくれるので、出来る限りダウンタイムの少ない運用を行いたい。その結果としてwordpressサーバは大胆な停止が行えなくなり、構造変更がまともに出来ず、古臭い構成に成り下がってしまう。クラウドに移行した一番のモチベーションは、複数台構成にすることで頻繁に更新出来る環境を維持したかったからだ。 最初のGMOクラウドでは、active/slave構成を前提に構築してしまったため、2台あったものの結局1台運用と変わらない状況だった。内部ネットワークの貧弱さが同期的なマルチマスターを嫌厭させたという見方も否めなくはないが。IDCFクラウドでは期待通りLANの形でクラウドが使えるため、マルチマスター構成の導入に踏み切った。まず、DBをMySQLからGalera ClusterのMariaDBに置き換え、更にアプリを配置するディレクトリをGlusterFSでマルチマスター化した。Web UIで更新を行うwordpressではDBと同期的にア
tech DBサーバ 比較 MySQL vs MariaDB 移行編 昔ながらのmaster/slaveでMySQLを運用してきたが、最近は大分考えが変わってきた。少なくとも自分の趣味環境においてはパフォーマンスより運用の利便性を優先しないと作業の生産性が改善しない。MySQLにおいてmaster/slave構成を取ってきたのは、趣味レベルにおいてはわずかでしかない性能を気にしての事。GMOクラウドからIDCFクラウドに引っ越して内部通信品質も大きく改善したので、今回はwordpressのDBをマルチマスターとなるMariaDBのGalera Clusterに移行してみる。 自分で開発したサービスならDBに対するreadとwriteを切り分けて、slaveを使いこなす事も可能だが、wordpressなどの既成のツールではそういう訳にもいかない。そもそもwordpressの複数台運用は何気に難易度が高く、DBだけマルチマスター化しても達成出来ない事もあって結局1台運用を続けてきた。作業時のみ2号機に切り替えて・・・とかやっていたが、たまの切り替えだと事故を起こすだけなので、結局1号機を短時間でメンテナンスするという運用になり下がってしまっていた。
tech 構成管理ツール比較 chef zero vs ansible もともとchef serverのよる構成管理を行っていたが、よりシンプルな仕組みにしたかったのでansibleに移行した。ansibleは処理も軽く、コードも構成もシンプルで気に入っていたのだが、難しい処理を扱い始めてくると表現力に物足りなさを感じてしまった。具体的には、素のpythonを書けないことのストレスと、pythonでの構造体操作がperlやrubyに比べるとやりづらいという点。その手間も相まって、Jinja2でのtemplate定義に悩むことが多かった。 構成管理ツールでは、ohaiで取得するような複雑な構造体からデータを取り出して、レシピの中で扱うことになる。pythonの場合、複雑な構造体からデータを取り出しづらいため、Jinja2の中でもif文やloop文を駆使して取り出すことになる。それに加えて変数スコープが厳密なため、更に手間がかかってしまう。こういうことを繰り返していると徐々にansibleの魅力が薄れていき、rubyでさくさく書けるchefに気持ちが戻ってきてしまった。chefは、rubyによる構造体の操作もやりやすいし、業務で使うことも多いし。 an
tech IDCFクラウド 仮想ブリッジ ネットワーク問題 今までも何度か触れてきた、IDCFクラウド環境のネットワーク問題。CentOS7インスタンスにLXCコンテナを作成して、そのコンテナを仮想ブリッジ経由でネットワークに繋げている。しかし、この仮想ブリッジ内のLXCコンテナがネットワーク的に不安定。例えばリモートのs3fsをマウントしようとするとコンテナが応答不能になってしまったり、別ノードのLXCコンテナとkeepalivedによるvrrp通信をさせようとすると応答不能になってしまったり。また、コンテナ再起動すると、しばらく外部と通信出来なくなるので、コンテナで複雑なことをやるのは二の足を踏んでいた。 しかし、なるべく自宅環境側と同じ構造を取らないと、chefのrecipeが複雑化してしまう。自宅のホストOSは最低限の仕事のみで、ほとんどのミドルウェアはLXCコンテナ上で動いている。この辺りの自宅環境とクラウド環境の違いがネックになり、作業効率が落ちてきたので本腰入れてクラウド環境のネットワーク問題を調べることに。不可思議な事象の中でも最も再現性の高い問題は再起動後のネットワーク不通問題。早い時はすぐに通信できるようになるが、遅いと
tech IDCFクラウド DNS冗長化 keepalived編 中外共用のbindをどのように冗長化させるか。前回、nginxのudp proxyを使ってみたが、期待していたproxy_protocolの設定がudpだと働かずに断念。別の方法を考える。bindの前段でロードバランスさせてしまうと、どうしても接続元がロードバランスするサーバになってしまうので、接続元によるzoneの切り替えが出来なくなってしまう。やはりbindそのものをネット上にむき出しにするのが最もシンプル。その状態でどのように冗長化を実現するのか。もうVIPによるフェールオーバくらいしかないか。うん？ VIPによるフェールオーバって自分の要件に対して実はものすごく適切な方法ではないだろうか。DNSに負担をかけるような仕組みを作るつもりはないので、DNSを負荷分散するモチベーションはない。冗長化を実現する過程でやむなく負荷分散になってしまっていただけだ。性能的には1台で充分、万一問題があったときだけ別のサーバにフェールオーバしてくれればよい。手元でzoneを書き換えて試験するようなこともあるので、寧ろ普段1台であることはありがたいくらい。しかもインターネットに直結するので、接続
tech IDCFクラウド DNS冗長化 nginx編 中外の出し分けをするbindをどのように冗長化させるかという話。LVSを使うと接続ソースが全てLVSサーバになってしまうため、振り分けも2系統、bind側のIPアドレスも2系統にしてmatch-destinationsで出し分けるしかなかった。もちろんこれで期待した動作は実現できるんだけど構造が複雑なのが不満。もっとシンプルな構成で実現できないかを模索する中で、改めてnginxによるtcp/udp proxyを検討してみる事にした。 振り分けにLVSを採用した理由をまとめてみると、まずはヘルスチェックをカスタマイズできる事。次にNATで振り分けられるため、ロードバランサーとその先のサーバの共存が可能なこと。つまりLVSサーバ上にDNSサーバをそのまま乗せる事ができる。これはノード数を少しでもケチりたい自分の環境においては非常にありがたかった。また、IDCFクラウド上で利用している仮想ブリッジが不安定なこともあって、幾つかの機能をコンテナではなくサーバ上で共存させたいというモチベーションと、シンプルな運用のために複数IPやポートずらしみたいなこともできる限り避けたい、というこだわりも
tech GlusterFS の Split-Brain 障害対応 導入以来、想像以上にタフに動いてくれているglusterfs。当初はcephfsとの選択を迷う時期もあったが、現時点ではglustefsが自分の環境にはフィットしている。2ノードの3TBディスク8本の構成なので、分散FSとしての性能はまったく期待していない。8本の中でRAID10的なdistributed-replicateを構成しており、その冗長性とネットワーク経由でのファイルシステムの共有に大きな価値を見出している。ファイルシステムレベルで冗長性を確保できたことによって、多くのミドルウェアの冗長性を気にする必要がなくなり、構成管理が非常にシンプルにすることができた。あくまで個人管理の趣味システムを前提とした話だが。 当初よく起きていた問題が、冗長化された2つのデータが異なってしまう障害。それをglusterfsではSplit-Brainと位置付けている。もしかしたらデータを3つに冗長化すれば、quorumでSplit-Brainを回避してくれるのかもしれないが、自分の環境では3ノードの冗長化は想像以上に性能が劣化したので見合わせている。発生するのはいずれかのノードを停止して再構
tech IDCFクラウド DNS冗長化 LVS編 IDCFクラウド上のnameサーバは中外兼用のbind。外向きには自分所有のドメインのゾーンを返して、中向きにはローカルゾーンも含めて答える。ダウンタイムは小さくしたいので2台で冗長化させておきたい。IDCFクラウドの仮想ルータはUDPのロードバランスが出来ないので自前で行う必要がある。枯れたやり方としてはLVSを使うことだろう。LVSで2台のbindをロードバランスしてみたところ、外からの問い合わせも中向けの処理が対応するようになってしまった。bindのmatch-clientsで処理分けしていたのだが、外からのものも含めて全てのリクエストソースがLVSサーバになってしまったからである。 対応する方法は幾つか思い付くが、まずやってみたのは中用と外用のVIPを分離すること。LVS上で2種類のルールを作って、一方はグローバルIPとNATさせて、もう一方はクラウド内サーバのresolv.confに書いておく。これで中と外の経路を分離できるので、match-clientsに中用のVIPを書いて、外用はanyにして処理分けを行う。結果から言うと、今度は全て外用で処理されてしまった。面倒くさ
tech IDCFクラウド cloudstack-api で LVS NAT IDCFクラウドに少しずつ環境を構築していっている。何よりもまずDNS環境を既存環境から移行させてしまいたい。クラウド上の2台のサーバにbindで立てたDNSをインターネット上からも問い合わせ出来るようにする。仮想ルータでのラウンドロビンはUDPに対応していないため設定できない。2台間のロードバランスはLVSに任せる。そのLVSのVIPにNATする形でインターネットからのアクセスを設定する。しかし、仮想ルータによるNATは仮想サーバのNICにアサインされているIPアドレスにしか繋げることが出来ない。なので、IDCFクラウドのAPIを利用してVIPに対するNATを設定する必要がある。 これらの方法もIDCFクラウドのブログにやり方が乗っているので、それを参考にする形で進めることが出来た。最初にcloudstack-apiのインストールを行うが、pythonで用意されたモジュールなので、pythonの環境から構築していく。pipに必要なパッケージをインストールして、pipを使ってcloudstack-apiをインストールする。インストールが出来たら、ホームディレクトリに.idcfrcと
tech IDCFクラウド LVS で負荷分散 IDCFクラウド上でLVSを使う分には、参考になる記事もあってそれほど難しくなさそうに思った。ただ、自分の環境の場合、仮想サーバ内でブリッジ接続したLXCコンテナ上でLVSを利用、あるいは仮想サーバ上でLVSを利用して、LXCコンテナに振り分けるといった構成を取りたい。まずはLXCコンテナ上でのLVS運用を検証してみた。コンテナ上では、kernelモジュールやパラメータを変更することはできない。ホストOSのそれを継承するだけなので、とりあえずホストOS側にipvsadmをインストールする。振り分けに必要なkernelパラメータ2つも有効化する。CentOS7だとnet.ipv4.ip_forwardは最初から有効。net.ipv4.vs.conntrackはipvsadmを動かさないと設定できなかったので、一旦ipvsadmを起動してから有効化した。 yum install ipvsadm sysctl net.ipv4.ip_forward net.ipv4.vs.conntrack systemctl start ipvsadm sysctl -w net.ipv4.vs.co
tech IDCFクラウド LVS+ansible で kickstart 環境構築 IDCFクラウド上での環境構築を着々と進めている。構成管理ツールをansibleに切り替えてから、初めてのクラウド環境対応なので、わりと細かいところから修正している。そもそも自宅環境とクラウド環境をVPNで繋いで、仮想的なプライベート・ネットワークを作るかどうかも悩んだ。現時点ではクラウドの独立性を優先して、それぞれ個別に環境を作っている。chefではリッチなサーバ環境を安価なクラウドで用意できなかったので、この辺りはansibleの軽量さに感謝している。ansibleの処理そのものを別管理にするのはコストが大きいので、同じgitで管理してhostsファイルを自宅環境とクラウド環境で違える形を取った。処理ロジックの中では、ansible_domainを使って処理分岐や変数の変更を行っている。例えば、こんな感じ。 --- - hosts: hostserver roles: - host - grub - glusterfs - { role: lvs, when: inventory_hostname in groups.lvs } - { rol
tech パブリック クラウド 比較 GMO vs IDCF 機能編 最初のクラウドとして、それなりに要件を満たしていたGMOクラウドALTUSを9ヶ月ほど使ってきた。しかし、その間にサーバ運用の価値観が大きく変わり、別のクラウドも触ってみたくなってきた。価値観の変化というのはマルチマスターの便利さ。スケールアウトによって更新処理が犠牲になるマルチマスターを避けてきたが、glusterfsの利用による構成管理の単純化に大きく心変わりした。同様にDBもmariadbのマルチマスターに変更して、wordpressのスケールアウトを可能にしたい。性能面でのスケールアウトはまるで必要ないが、運用面で複数台運用ができるとローテーションによる再構築やメンテがし易くなるので実用的。 クラウドとは言え、最低料金で運用したいのでアーカイブ領域すら使わない2台運用。それでもブログのおかげでやっと最近黒字になってきた程度ｗ 自宅環境の考えと一緒なのだけど、基幹機能を落とせないから古いOSを使い続けるという悪循環には2度とはまりたくない。サーバAからサーバBを生成して、サーバBからもサーバAが作れるという環境にする必要がある。これには2台が同じ機能と同じデータを持つ必要があ
tech 分散FS 比較 cephfs vs glusterfs (3) 再検証編 前回試した際に、動作が不安定だったために具体的な検証すら見送ったcephfs。実は4月にcephfsのstable版を含むcephのメジャーリリースがあった。評価してみたいなあと思いつつも、ファイルサーバ用途としてはglusterfsが充分な機能を持っていたので、今の今まで後回しにしていた。ansibleとか録画サーバとかいじってたからだけど。そんな満足度の高いglusterfsだけど、唯一の欠点がopen()が異常に遅い事。大きいファイルを置くだけで、参照も更新も少ないファイルサーバくらいならいいんだけど、頻繁に更新が伴うような用途には向かない。例えば、lxcで作るコンテナの配置先とか。 コンテナに必要なファイル一式をglusterfs上に置ければ、そこをマウントするだけで、どのノードでもそのコンテナを起動可能になる。同じコンテナを複数ノードに作るよりも、そういう形で冗長化を図るのもありかと思った。コンテナ構築時にはlxcのファイルキャッシュから多くのファイルコピーが行われる。配置先をglusterfsにすると、これがもうびっくりするくらい遅くなるので使う気になれない。ローカルデ
tech ansible gather_facts チューニング 前回、chefからansibleへの移行記事をまとめたが、その際にさらっとgather_factsの高速化に時間を使ったと触れた。そもそも素でansibleを使うとデフォルトで処理前段にgather_factsの処理が入る。これが何をしているかというと、各ノードのOSやスペック、ネットワーク情報などの収集だ。ansibleはサーバサイド・プッシュな動きをするので、ansible-playbookを実行すると対象ノード全てに処理を行う。gather_factsの処理も同様で対象ノード数に比例して処理時間が伸びていく。1ノードならまだしも、10ノードを超えだすとその待ち時間は耐え難いものに。chefサーバの場合はサーバプロセスが存在したので、その中でこの手の情報をキャッシュしてくれていたのだろうが、ansibleにはサーバプロセスが存在しないため、毎回律儀に各ノードから取得する羽目になる。 gather_factsで取得されるような情報は、原則的に固定値というか殆ど変化がないような値ばかりだ。それを毎回毎回時間かけて取りにいってしまうというのは無駄でしかない。序盤の検証段階では特
tech 構成管理ツール比較 chef vs ansible 自分のevernoteを見返すと3年前からchefを使っているようだ。当初からchef server構成を使っていたため、冗長化の方法に何かと頭を悩ましてきた。個人で使う分にはそれほど更新頻度は高くないので、定期的にrsyncしていれば何とかなるのだが、それでも切替のときには一旦止めてreconfigureして再起動のようなコールドスタンバイくらいしか方法がなかった。また、chef server上ではelastics searchやpostgresqlなど、多くのミドルウェアが動いてしまうため、独立ノードで使う事になってしまう。貧弱なクラウド環境での動作は性能的にイマイチなので、クラウド環境と自宅環境をopenvpnで繋いで、自宅でchef serverを動かす形を取っていた。 この構成を見直すきっかけとなったのがglusterfsを使い始めた事。glusterfsの冗長性を利用して、glusterfs上にlxcコンテナを作成、そこでchef serverを動かす事を考えた。しかし、glusterfsはfile open処理が非常に遅く、やたらとファイルにアクセスするchefの処理
media ひかりTV IPv6問題 再発 ひかりTVのIPv6問題とは言っても、最も影響の大きい無線機器は別経路になっているので、特に性能問題が起きると言う訳ではない。ひかりTVのマルチキャスト放送波はMLDスヌーピングの機能があれば専用チューナー(ST-3200)のみに送られる事になる。うちの場合は、根元のブロードバンドルータと中継するスイッチ(EHB-SG2A08)がMLDスヌーピングに対応しており、マルチキャストが他のノードに溢れる事はない。が、今までもEHB-SG2A08のIPアドレスを変更したりすると、何故か放送波が届かなくなったりと不穏な兆候はあった。設定し直すと回復するので、だましだまし使っていたのだが、マルチセッション障害の対応でブロードバンドルータがPR-400NEに変更となってから、ひかりTVの放送波がまったくチューナーに届かなくなってしまった。 切り分けのために、EHB-SG2A08スイッチのアップリンクを直接ST-3200チューナーに繋いでみる。これで2FにあるPR-400NEルータとST-3200を直結している格好になり、放送波は受けられるようになった。やはり中継するEHB-SG2A08が何か悪さ
tech wordpress 修正のプラグイン化 wordpressの細かい修正を割りとラフにハードコーディングしてきたんだけど、さすがに量も増えてきたし、バージョンアップも多いし、毎回直すのが億劫になってきた。という訳で、いい加減バージョンアップに影響を受けない修正方法を検討する。何となく想像は付いていて、専用のプラグインを作り、コアモジュール以外の部分で修正を行えるように準備する。そのプラグインの中でwidget作ったり、パラメータを上書きしたり、実現したいカスタマイズを実装していく。 wp-content/pluginsの下に自分用プラグインとしてディレクトリを作り、そこに数々の変更を集約する。中心となるphpは他のphpを読み込むだけのphpとした。まずはプラグインの集約から。コマンドリファレンス用に作ったページも当初は他のプラグインのテンプレートを改造して実現していたが、既にazindexという名のプラグインとして実装し直していた。中身はSQL投げてhtmlを書いたものをadd_shortcode()するだけ。このプラグインもモジュールの1つとして移動させる。 function custom_azindex (
tech ドコモ光 マルチセッション 完結編 先月、散々振り回されたPR-S300SEでのマルチセッション。諸々交渉した挙げ句、結局は別機種のルータを手配してもらえる事に。あれから早一ヶ月、新ルータの調子はというとすこぶる快調。PR-S300SEのときは1週間後に不具合が再発したことがあったので、今回はゆっくりと様子を見た。新たに準備してもらったルータは『PR-400NE』という機種。幾つかある選択肢の中で、旧機種にUIが似ているというのでそれを理由に。逆に同種の不具合が、という一抹の不安がよぎらなくもなかったが。。。 結線を済ませ、電源を投入。旧機種と同じようにLANケーブルで直結すると192.168.1.xのIPがDHCPでもらえる。ブラウザで192.168.1.1へアクセスすると、新ルータの設定画面へ辿り着く。初回接続時にパスワードの設定を求められる。終えるとPPPoEの設定画面に移るので、ドコモnetの接続情報を入力する。これで、インターネットへの接続はとりあえず完了。改めて設定画面へログインすると、確かにPR-S300SEとそっくり。うちはLinuxサーバがDHCPを担当しているので、DHCPサーバ機能をオフる。つい
tech 分散FS 比較 cephfs vs glusterfs (2) glusterfs編 前回その不安定さからcephfsの利用を見送ったので、今回はglusterfsを評価してみる。glusterfsの特徴は他の分散ファイルシステムに比してシンプルである事。管理ノードみたいなものは存在せず、メンバー全員が公平にファイルを管理してくれる。全く同じノードを幾つも作って、それが一体的に動いてくれるので、運用管理効率は高いと言える。自宅環境のような多くても数台程度のクラスター管理であれば、cephよりglusterfsの方が合っているように思う。 cephはブロック単位の分散だったが、glusterfsは幾つか選択肢がある。 1. distributeと呼ばれるファイル単位の分散 2. stripeと呼ばれるraid0のような分散(ブロック単位) 3. disperseと呼ばれるraid5のような分散(ブロック単位) 4. これらと組み合わせる事が可能なreplicate構成 1〜3と4を組み合わせる形で冗長化を担保する。例えば、1と4ならreplicated-distribute、1と3ならreplicated-disperseのような構成になる。 それ
tech 分散FS 比較 cephfs vs glusterfs (1) ceph編 自宅の超重要データはdropboxに同期したので一安心。しかし、それ以外にも5TB超の有象無象のデータがある。中身は過去のメールのバックアップやPCのディスクイメージ、CDやらDVDのiso、果てはPSPやらPS2のisoまで。もはや必要かどうかすら怪しいが、消すのも面倒なので貯まっているようなものたち。3TBx4本のraid5を2つ作って運用してきたんだけど、有効容量が8分の3という非効率さ。加えて、同期用のcronがしばらく消えていた。cronの仕込みをchefで管理していたんだけど、recipeの修正ミスでした。 こういうことがあり、改めて自宅のファイルサーバの冗長環境を見直す。できれば手動rsyncなどを使わずに仕組みの中で同期して欲しい。ついでに何とかしたいのは、サーバ間のファイル共有と共有スペースの冗長化。ヤフオクのお陰でノード数が増えて、現在サーバ用途は4台。4台とも同じデータを見たいが、そういうスペースが作れていない。raid5のディスクをnfsで共有してもいいんだけど、nfsは割りとセンシティブなのでダウンしたときのインパクトが怖い。という訳で、いまどきの分散ファ