iPhoneにSIPをしゃべらせて、自宅のAstariskに接続している方を見つけました。香港にいながら自宅の電話をiPhoneで使えるんだそうです。
この方法であれば、skyp アウトに比べて遅延もなさそうですし、発番も怪しい番号にならずにすみそうです。
現在、会社の電話環境をastarisk化しようとしているのですが、うちでもこれ使えるかもしれません。
- 2009 年 2 月 19 日
- [ android ]
最近オフィスの電話の調子が悪くて困っています。既に製造停止から10年選手の端末をつかっているため、代替機もなく修理も出せない状況です。
そんな背景から、元交換屋としては、asterisk を使って社内の電話を制御したい虫がうずうずしています。
当然、端末としてはSIP対応のAndroidが欲しくなってきます。
asterisk + (Android + SIP)が組めると、いままで出来なかったような社内サービスが実現できると思うのですが、どうでしょうか?
- 2009 年 2 月 17 日
- [ Column ]
昔は、SCSIならAdaptecの2015や2010。IDEならiodataのdelta2あたりをつかっておけば、いざっていうときは、RAIDカードを撤去してマザー直指しで復旧作業が出来ました。
しかし、昨今のHardware RAID カードは、メーカー独自フォーマットが主流となってしまいました。その影響で、サーバメンテナンス業者は、
- RAIDカードが壊れると、そのハードディスクは、マザーに直接指しても全く読めないハードディスクになってしまう。
- RAIDカードが製造中止になるとかなりまずい。
- 緊急時に別マシンで複製したりバックアップからリカバリーしたりするにも常に同じRAIDカード環境がないと作業が出来ない。
というリスクが伴います。
それでは、LinuxのSoftwareRAIDにしたら?という話になります。
ハードウエアRAID vs ソフトウエアRAID。
この論議を机上論で行うとハードウエアRAIDに軍配があがるのですが、実際の泥臭い現場の状況からすると、ハードウエアRAIDは結構痛い目に会うことが多いのは事実だと思います。これまで14年間。数百台のサーバを作り最後まで看取ってきましたが、ハードウエアRAIDのホットスワップで得た恩恵の回数と、RAIDカードを使った事によるトラブルに巻き込まれた回数とあまり変わらないように思います。やはりシステムの摂理として、シンプルなのが一番で、複雑になればなるほど事故も増加します。
そこで、システムが冗長化になっていれば、ホットスワップが出来ないSoftwareRAIDの方がメリットが多いのではないか?という切り口から、いまさらながら、ハードウエアRAID vs ソフトウエアRAIDのスピードテストを行ってみました。速度さえトントンであれば、この際、ハードウエアRAIDを捨てるのも現場的にはありかと思ったからです。
結果は、以下の通り。弊社ではこれを機会に冗長化してあるシステムにおいて、ハードウエアRAIDはやめる事にしようと思います。
■測定環境
| マザーボード |
Super X5DPR-8G2+ |
| CPU |
Intel(R) Xeon(TM) CPU 2.40GHz x 2 |
| メモリ |
2GB |
| ハードウエア RAIDカード |
3ware 8006-2LP |
| ハードディスク |
ST31000333AS x 2 |
| OS |
CentOS 4 |
| データベース |
PostgreSQL 8.1 |
■ 測定結果
以下SW=Software RAID, HW=Hardware RAID。水色が勝者。
▼bonnie++
○アクセス速度
|
Sequential Output |
Sequential Input |
Random |
Sequential Create |
Random Create |
| Per Chr |
Block |
Rewrite |
Per Chr |
Block |
Seeks |
Create |
Read |
Delete |
Create |
Read |
Delete |
| K/sec |
K/sec |
K/sec |
K/sec |
K/sec |
/sec |
/sec |
/sec |
/sec |
/sec |
/sec |
/sec |
| SW |
29738 |
76693 |
28425 |
26180 |
63601 |
387.5 |
33087 |
211403 |
35711 |
34286 |
273394 |
35336 |
| SW(-n 256) |
29221 |
76877 |
28401 |
26384 |
62070 |
377.2 |
19978 |
200433 |
509 |
11538 |
252888 |
266 |
| HW |
27081 |
57677 |
22943 |
25966 |
56936 |
379.2 |
29879 |
N/A |
N/A |
N/A |
N/A |
32170 |
| HW(-n 256) |
27983 |
56850 |
23303 |
24297 |
54209 |
352.6 |
19401 |
194718 |
715 |
11494 |
246347 |
377 |
○CPU使用率
|
Sequential Output |
Sequential Input |
Random |
Sequential Create |
Random Create |
| Per Chr |
Block |
Rewrite |
Per Chr |
Block |
Seeks |
Create |
Read |
Delete |
Create |
Read |
Delete |
| %CP |
%CP |
%CP |
%CP |
%CP |
%CP |
%CP |
%CP |
%CP |
%CP |
%CP |
%CP |
| SW |
97 |
44 |
11 |
78 |
10 |
1 |
97 |
100 |
100 |
99 |
100 |
100 |
| SW(-n 256) |
95 |
45 |
11 |
79 |
10 |
1 |
70 |
100 |
2 |
40 |
99 |
1 |
| HW |
89 |
32 |
9 |
75 |
10 |
1 |
90 |
N/A |
N/A |
N/A |
N/A |
98 |
| HW(-n 256) |
91 |
31 |
9 |
70 |
9 |
1 |
70 |
99 |
2 |
41 |
99 |
1 |
▼pgbench
○条件
transaction type: TPC-B (sort of)
scaling factor: 100
number of clients: 50
number of transactions per client: 200
number of transactions actually processed: 10000/10000
○結果
| SW |
123.03785 tps |
| HW |
95.591599 tps |