DATE:
--/--/--(--) --:--
CATEGORY:
スポンサー広告
上記の広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書く事で広告が消せます。
DATE:
2009/10/14(水) 16:40
CATEGORY:
LVS
ipvsadm+keepalivedによる構成の予定だったんだけど
お上からrpmでおkされたために、
rpmでおkな
ipvsadm+ldirectordによる構成で
インストールはyumで
yum install -y ipvsadm heartbeat-ldirectord
で、ipvsadmの設定は行わず、
直接ldirectord.confを編集
# Global Directives
checktimeout = 10
checkinterval = 30
autoreload = yes
logfile = "/var/log/ldirectord/ldirectord.log"
quiescent = yes
emailalert = "hogehoge@example.com"
emailalertfreq = 3600
emailalertstatus = all
# Virtual Service Settings
virtual = LVSの仮想IP:ポート
real = リアルサーバのIP:ポート masq
real = リアルサーバのIP:ポート masq
checktype = チェック方法
scheduler = スケジューリングアルゴリズム
protocol = tcp
こんな感じに設定するとNAT構成のロードバランサができた。
できなくても責任はとりませんw
DATE:
2009/09/01(火) 00:47
CATEGORY:
LVS
わけあって現在負荷分散サーバを構築中
今回はリアルサーバに外部用IPを振る余裕はないのでNAT構成で
yum -y install ipvsadm
ipvsadm -A -t NATの外向きIP:サービスポート -s lc
ipvsadm -a -t NATの外向きIP:サービスポート -r リアルサーバのIP:サービスポート -m
ipvsadm -a -t NATの外向きIP:サービスポート -r リアルサーバのIP:サービスポート -m
DATE:
2009/06/30(火) 22:18
CATEGORY:
Windows
最近EeePCをデータ端末セットで買った。
使ってみて思ったのが、
こいつの力では処理はできない。
外のリモートサーバ的な何かに処理をお任せしないとちょいと重い。
むしろそれこそがこいつの真価だと思った。
それでも電波環境によってはちょいとつらい。
DATE:
2009/02/05(木) 13:57
CATEGORY:
DRBD
なんかDRBDのことしか書いてないのでカテゴリに追加
で、本題。
DRBDの片ノードダウン時に生きている側のcstateをStandAloneにしないための方策。
やることは簡単。
何をするかというと、
予期しないダウンに対して、wfc-timeoutによってStandAloneにしないようにするというだけ。
ついでに通常時にもwfc-timeoutで以下略
drbd.confの中に
wfc-timeout 0;
degr-wfc-timeout 0;
をstartupに記述すればよいだけ。
ただそれだけ。
簡単でしょ?
DATE:
2008/11/23(日) 17:44
CATEGORY:
DRBD
GFS2をでフォーマットしたDRBD領域に対して、両方のノードから書き込みを行ってみた。
環境はわかる範囲で以下
OS:Fedora9 i386
CPU:PentiumD 840
RAM:4G(32bitの都合で3300M強までしか認識されない)
HDD:メーカーがわからないけどSATA2(?)
実行コマンド
i=0;while [ $i -le 10000 ]; do echo abcdefgh,$i >> /home/drbd/test.log ;i=`expr $i + 1`;done
i=0;while [ $i -le 10000 ]; do echo hgfedcba,$i >> /home/drbd/test.log ;i=`expr $i + 1`;done
これを両方のノードからおのおの実行する。
そうすると結果(一部抜粋)が
・・・
hgfedcba,442
hgfedcba,443
hgfedcba,444
abcdefgh,1
5
hgfedcba,446
・・・
ってな感じでこっちが意図しない結果(5とか)が出る。
おそらく、という意味をこめて補完するとこの5は"hgfedcba,445"が書かれるべきものだったのだろう。
で、こんな感じの実行エラー的なものは片方の書き込みが終わるまでほぼ100%の確率で出てきた。
といっても今回残ってる結果がこの一回しかないってのも問題だけど。。。
記憶をたどれば、
・・・
hgfedcba,440
hgfedcba,441
hgfedcba,442
hgfedcba,443
hgfedcba,444
bcdefgh,1
abcdefgh,2
abcdefgh,3
abcdefgh,4
abcdefgh,5
abcdefgh,6
hgfedcba,446
・・・
こんな感じの結果もあった。
で、これの問題がGFS2なのかDRBDなのかを探してみるためにocfs2を入れてみることに。
その結果
・・・
hgfedcba,14
abcdefgh,197
hgfedcba,15
abcdefgh,198
hgfedcba,16
abcdefgh,199
hgfedcba,17
abcdefgh,200
・・・
こんな感じに交互にくるのが終わるまで続く。
charが一個飛ぶとか一行空くだとかのエラーっぽいものもない。
これはいい感じw
だとするとGFS2が悪いのか、DRBDとの相性が悪いのかのどっちかになるんだけど、
残ってる結果を考えると、GFS2的な結果の残り方(同時に書きこんでいる間はマスタ側の書き込みが優先される)なのでGFS2の挙動としては悪くない。
とすると原因は後者か。