2011年 6月 16日

　Apache Traffic Serverは、米Yahoo!が開発・運用していたキャッシュサーバー。2009年にオープンソース化され、現在はASFの下で開発が進められている。 大規模環境への対応が特徴で、キャッシュ機能のほか、セッション管理、ロードバランシング、認証、ルーティング、リクエストのフィルタリングといった機能 を備えている。

　バージョン3.0では、キャッシュ、プロキシ、速度、信頼性などさまざまな面で強化を図った。要求の多いWebページや画像、Webサービス呼び 出しなどをキャッシュして再利用することでサーバーへの負荷と帯域を削減、レスポンス時間を改善するという。SMPハードウェアにおけるスケーラビリティ も改善された。これらの強化により、ベンチマークでは毎秒20万件以上の要求処理を達成した。これは、バージョン2と比較すると277％の改善となるとい う。

　そのほか、64ビット対応やIPv6対応も改善した。Web Cache Communication Protocol（WCCP）にも対応し、APIの改善など拡張性も強化した。

　Apache Traffic Server 3.0はプロジェクトのWebサイトよりダウンロードできる。

Apache Traffic Server
http://trafficserver.apache.org/

キャッシュプロクシサーバー「Apache Traffic Server 3.0」リリース、性能が大幅に向上 - SourceForge.JP Magazine : オープンソースの話題満載

11ヶ月前 | 固定リンク | 2011年 6月 16日 |

2011年 4月 29日

Silver Storm（日本ラッド）を試してみる

Posted by shimotomai on 2011年4月15日 Leave a comment (0) Go to comments

Silver Stormの主なスペック
・基本スペック
　・月額100円。1年分前払い。
　・HDD10GB。Webとメールサーバが別なので振り分ける必要あり。
　・独自ドメイン使用可能。
　・マルチドメイン30個まで。
・Webサーバ（VPS）
　・中身はOpenVZのマネージドなVPS。OSはCentOS 5.5。
　・保証メモリ128MB、最大384MB。
　・VPSだが、サーバの設定変更は不可。.htaccessは使える。
　・cron/sshは使えない。
　・Apache（Perl/PHP/Ruby/Python）、MySQLがインストール済み。
　・スクリプトでsendmailやftp関連の関数は使用不可能。
　・ApacheとMySQLの設定が大量にメモリを使う設定なので、384MBをすぐにオーバー。
　　MediaWiki等をインストールしてみるとすぐにサーバエラーになってテストにすらならない。
　・実質的にMySQLは使えないと思って良い。SQLiteで動かすしかない。
　・telnet.php等でMySQLを停止出来るが、起動させる手段が無い（多分root権限必要？）。
　　どうせ使い物にならないなら停止させても良いと思うけど、
　　WebメーラーとかでMySQLを利用しているので止めると動かなくなる。
　・現状、ほぼ静的コンテンツ専用と言っても良いレベル。
・Mailサーバ（共有？）
　・Webサーバ（VPS）とは別管理。
　・アカウント数無制限。メーリングリスト10件まで。
　・迷惑メールフィルタとかウイルスチェック有り。
　・CatchAllの設定が無い。
　・説明書にはメールサーバだけこっちで管理させる方法が書いてないが、以下の設定で行けた。
　　（Value-Domain）
　　mx smtpin.silver-storm.jp. 10 [サブドメイン]
　　txt [サブドメイン] v=spf1 a:smtpout.silver-storm.jp ~all

Webサーバは、メモリ保証とか書いてるが、ApacheやMySQL等の設定ファイルが弄れないので保証メモリ範囲内で動かす事が出来ない。デフォルト状態で既に保証メモリをオーバーしてるため、何のためのメモリ保証なのか理解不可能。
MySQL使えるとか書いてるけど実質的に使い物にならない。
中身VPSなんだから設定ファイルぐらい弄らせて欲しい。

月100円なので、独自ドメインのメールサーバとして使い、Webサーバは静的コンテンツ専用として使うのが良さそう。
XREAのMail&Backupプランとあまり値段変わらないのにHDD10GBと大容量で、かなり使えないけどWebサーバが付いてるのは十分魅力的だと思う。

Webサーバさえ何とかしてくれればもっと魅力があるサービスなんだけどなぁ・・・。

現状、Webサーバとして使いたいならCORESERVER(CORE-MINI)の方が良い。
年3000円だから2.5倍ぐらいするけど。

Silver Storm（日本ラッド）を試してみる | 下斗米の技術メモ

メールサーバのソフトはPostfixな模様です。

1年前 | 固定リンク | 2011年 4月 29日 |

2011年 4月 21日

試算から

この簡単な試算の結果、以下のことがわかる。

• 本当に同時にディスクが複数台壊れる確率だけに注目すると
  • RAID-1+0 の場合は年あたり 0.001% くらいの確率でデータロストする
  • RAID-6 の場合は年あたり 0.0000002% くらいの確率でデータロストする
  • 基本的にどちらも低過ぎてあまり考える意味はないけど、それでもRAID-6の方が何桁も安全
• 1台のディスクがfailしたあとのリカバリ中の故障の確率を見ると
  • RAID-1+0 の場合は 0.23% の確率でデータロストする
  • RAID-6 の場合は 0.019% の確率でデータロストする
  • NetAppの試算とは数字がひと桁違うが、アレイの構成台数の前提やリビルド前後期間のとりかたなどで変わってくる
  • 疑われる向きは自分のアレイ構成で計算してみればいいと思いますよ計算式は全部上にあるから

結論

単純な安全性だけ考えるならRAID-6はRAID-1+0(2重化)よりすぐれている。*11

もちろん実際の選択においては性能、要求容量に対するHDDあたり容量のトレンドと冗長性の兼ね合い、手に入るRAIDコントローラの機能および価格なども考慮の上で選択するべきであって、安全性だけを考えればいいというものではない。ただし性能要件が厳しいことというのは実際にはそんなに多くないはずなので、きちんと考えた上でならより安価で安全なRAID-6を選択するというのは現実的なものでしょう。

RAIDレベルの話: 1+0と6はどっちが安全か？ - tagomorisのメモ置き場

壊れるのはHDDとは限らないわけで、RAIDコントローラの故障率も割とあります。
私の提案としては以下の通りです。
いずれにせよどこが壊れるか分からないので、物理的に分かれた複数台での冗長化は必須です。

【HDDの利用効率を重視する場合】
物理的に分かれたRAID-6マシンを2台用意してミラーする。

【リスクを抑えたい場合】
容量単価が安い現在、割り切ってRAID10程度にする。
そして、それらをミラーする。

※ ミラーさせる方法は色々あるが、簡単なrsyncを使うのが手軽ですね。
ファイル数が多かったり、リアルタイム性を重視するならDRBDが良いです。

1年前 | 固定リンク | 2011年 4月 21日 |

2011年 2月 11日

具体的なサーバの構成は次のとおり。

1. エッジサーバ
   • ヘッド用エッジサーバ
     少ない種類の動画の大量配信に特化（＝祭り用サーバ）
     同時接続数：20,000　要求ストレージ速度：高速　容量：低→SSD化＋10GbE化を進めスケールアップ
     
   • ミドル用エッジサーバ
     比較的新しめで、そこそこ見られている動画の配信
     同時接続数：120,000　要求ストレージ速度：大
     
   • テール用エッジサーバ
     同時接続数：60,000　要求ストレージ速度：最大（2TB程度）
2. オリジンサーバ
   エッジサーバにキャッシュされていない動画をここから取得 要求ストレージ：極大　ストレージサーバへのアクセスを極少にする。
   
   
3. ストレージ
   容量数百TBのストレージ：現3台
   
   • 来年にはPBに到達
   • NFSでアクセス→とても扱いやすい。現場としては今後もこれで行きたいという意見。
   要件
   
   • 可用性、スケーラビリティ、コスト→こちらがより重要である。
   • 速度はそこそこ必要（3～4Gbps）

　この辺りから、ではドワンゴのアプローチはどのようなものか？というまとめに入りました。

1. 自前主義：アプリケーション設計とサーバ構成で課題クリア
   多段キャッシュ、負荷分散、アクセス頻度による動画の置き場所調整, etc.
2. それらを実現してくれる製品はあるがあえて採用しない（例：SSD/HDDハイブリッドストレージ等）
3. 自前主義のメリット
   
   • 各レイヤーのリソース配分の自由度、スケーラビリティ
   • 個々のコンポーネントに求める要件がシンプル→製品選択幅広。混在がしやすい。
4. 自前主義のデメリット
   
   • 集積度が低くなりがちである。
   • 場所代、電気代の問題

　今後ドワンゴとして求めているストレージ製品は、

• ドライブレベルでは、SSD導入。また高速・長寿命であること。
• ストレージレベルでは、安価なHDDの大量積みができること。大ボリュームとして扱えること。

だそうです。

ニコニコ動画のストレージの話を聞いてみた: 日々記―へっぽこライブラリアンの日常―

1年前 | 固定リンク | 2011年 2月 11日 |

2011年 1月 19日

現在自作サーバを1年運用してきましたがこれらがどのように変化したかについてまとめてみます。

「低価格」
　　実際サーバを自作すると言う事におきまして、低価格を期待している部分があると思うのですが、実際問題としてそこまでアドバンテージが出なくなってきたと言う所が正直な部分としてあります。
　　1Uのエントリモデルの価格がかなり下がってきていると言う所が大きいです。ですので、通常の1Uサーバを自作の様にカスタマイズして使う場合もかなりあります。
「低消費電力」　
　　最近のサーバ機は電力効率は良くなってきていますが、そもそもの消費電力はある程度以下にはなりません。そのため自作のメリットは大きいです。
「省スペース」
　　サーバはブレード機等で無い限りは1U以上を基本としており、ブレード機は導入障壁が高い（エンクロージャの管理、高い消費電力）事を考えるとやはり1U/2U機のフレキシブルな運用は捨てがたい魅力です。
　　フレキシブルな運用を殺さずに省スペースを目指すと自作のバランス感覚は捨てがたい、という事になります。
「適材適所」
　　どうしても購入できるサーバは僕らの環境を理解して作ってくれているわけではないので、本当に欲しいスペックのサーバにならない場合もあります。それは最大公約数的なスペックのサーバといえるかもしれません。(※2)
　　本当に欲しいスペックのサーバは作らないと無い、と言う状況は少なくはありません。
　　ただし、（サーバ用途として出ているPCパーツではなく）コンシューマ向けPCパーツを使用することが多い自作サーバでは、Memcached、MySQL等では、メモリ量で要求に答えられない場合は増えています。(※3)

アメーバを支える自作サーバのいままでとこれから｜サイバーエージェント 公式エンジニアブログ

2010年までは自作サーバはありでしたが、今は、メーカー製でもうまい事すれば性能の割に結構安く済みます。

1年前 | 固定リンク | 2011年 1月 19日 |

2010年 12月 14日

代表的なOSSのサーバ監視ツール

OSSのサーバ監視ツールにはさまざまな種類が存在し，代表的なツールとして「Nagios（ナギオス）」， 「Zabbix（ザビックス）」，「Hinemos（ヒネモス）」，「GroundWorkMonitor（グラウンドワーク・モニター）」， 「Xymon（シモン）」などがあります。それぞれ監視サーバの対応OS，管理対象となるエージェントの対応OS，管理インタフェース，監視データの保存 方法，表示方法などが異なります。特に管理インタフェースの日本語対応や監視設定方法，管理データの保存方法などは注意が必要です。

Nagios

Nagiosは，OSSのサーバ監視ツールの中で最も実績があり，日本語の情報も充実しています。元々は「NetSaint」の名称でリリースされ，バージョンアップを重ねてきましたが，現在はNagiosに引き継がれています。

Nagiosは，稼働監視をプラグインによって行う点が特徴です。基本機能で監視できる項目は多くありませんが，専用のコミュニティサイトに公開されている多数のプラグインを利用して監視項目が追加できます。プラグインは利用者が独自に開発することも可能です。

Nagiosでは，監視設定をテキストファイルに保存します。そのため，設定がやや複雑で管理も煩雑になりがちです。障 害の発生履歴もテキストファイルに記録されます。履歴データは最終値のみが保存されるため，過去のデータを参照することができません。収集した情報は Webブラウザで表示できます。ただし，障害表示は一覧表示のみに対応し，情報収集機能で取得した過去のデータは表示できません。また，リソースグラフを 作成も不可となっています。監視結果は基本的にメールでシステム管理者に通知される他，監視サーバ側のスクリプト実行に対応しています。

Zabbix

Zabbixは，ラトビア共和国のZABBIX SIA社が開発を行っているサーバ監視ツールです。開発を企業が行っていることから商用サポートが充実しています。Nagiosより後発であるため，利用実績は乏しいものの，日本にもコミュニティサイトが存在し，さらにミラクル・リナックス社が日本における商用サポートと導入サービスを提供しています。

監視対象のエージェントOSは，Linux，Windows，Solaris，AIX，HP-UX，Mac OS X，FreeBSD，OpenBSDと幅広く対応していることから，複数のサーバやネットワーク機器をZabbixで一元管理できる点がメリットです。

監視設定はWebブラウザから行います。ほとんどが選択式なので，設定はいたって簡単。専用エージェントも不要のため外 部からも設定できます。収集したデータは指定した期間分だけRDBMSに蓄積され，監視対象や項目ごとにデータの参照が可能。高度な表示機能を利用してグ ラフィカルなグラフを作成したり，詳細なレポートや見やすいマップを作成したりすることで，リソースの使用傾向や障害傾向が的確に把握できます。監視結果 はメール通知と監視サーバ側のスクリプト実行の他に，エージェント側でのスクリプト実行に対応しています。

その他

Hinemos

NTTデータが開発した国産のサーバ監視ツールです。日本で開発が行われているため，日本語の情報が充実しています。監 視設定は専用クライアントを用い，収集したデータは指定した期間分だけRDBMSに蓄積されます。監視機能の他，ジョブ管理，性能管理，一括制御の機能を 備えています。

GroundWork Monitor

米GroundWork Open Source社が開発を行っているサーバ監視ツールです。Nagiosなど複数のOSSを組み合わせて一元管理を実現しています。日本コミュニティが存在する他，富士通SSLが日本における商用サポートと導入サービスを提供中です。

Xymon

「Hobbit」の名称で提供されていたサーバ監視ツールで，OSSの「BigBrother」のアドオンソフト 「bbgen」をベースとしています。監視設定はテキストファイルで行い，収集したデータはRRD Toolsを介して保存されグラフの表示が可能です。導入実績は豊富ですが，日本語情報は少なめです。

Hosting Department：ホスティングを活用するための基礎知識：第18回　サーバ運用監視のノウハウ（その2）｜gihyo.jp … 技術評論社

1年前 | 固定リンク | 2010年 12月 14日 |

2010年 7月 31日

まず基本仕様

* CPU 2コア
* メモリー 512MB
* HDD 20GB
* ネットワーク 100Mbps(いちおうの上限)
* リモートコンソール付き
* 再起動、再インストールは、セルフサービスでコンパネから可能

ホスト側は、QuadCore Xeonで、1Gbpsにて上位スイッチに接続し、10Gbpsでさくらインターネットの基幹ネットワークに接続しています。
（クローズドベータテスト中に400Mbps位出たという記事もありましたが、さすがに対策する予定です）

ハイパーバイザーは、巷の格安VPSで多く利用される、VirtuaozzoやOpenVZ、Xenの準仮想化と異なり、KVMで完全仮想化になっています。
完全に512MBの実メモリを割当しますから、ホストOS側でスワップされずパフォーマンスが低下しないですし、ゲスト環境側でスワップを用意することも可能です。

実メモリは、ゲストで必要とするメモリ容量の1.5倍?2倍程度を搭載しています。
というのは、ホストOSのメモリの2/3以上をゲストに割り当てると、過負荷時のレスポンスが急激に悪化したり、不安定になったりということが言われており、当社でも再現されているので、余裕を持った設計にしています。
さらに、ホストOSのメモリの余裕を持たすことで、ディスクI/Oも劇的によくなります。
ゲストOSのスワップ時でも、ホストOSのキャッシュに入っていれば、メモリの延長上といえるかもしれません。

このように、100Mbpsインターフェース、20GBのHDD、2 CPU、512MBメモリといっても、同種のVPSサービスとは一線を画します。
その上で、「格安VPS」といえる価格帯で出す予定にしていますので、海外にも増してメリットのあるサービスになるのではと考えています。

….

さくらのVPSの初期状態において脊髄反射で感じるのは「思いのほか空きメモリが少ない！」ということです。

ps -aux結果

USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 0.0 0.1 10348 688 ? Ss Jul15 0:00 init [3]
root 2 0.0 0.0 0 0 ? S root 3 0.0 0.0 0 0 ? SN Jul15 0:00 [ksoftirqd/0]
root 4 0.0 0.0 0 0 ? S root 5 0.0 0.0 0 0 ? S root 6 0.0 0.0 0 0 ? SN Jul15 0:00 [ksoftirqd/1]
root 7 0.0 0.0 0 0 ? S root 8 0.0 0.0 0 0 ? S root 9 0.0 0.0 0 0 ? S root 10 0.0 0.0 0 0 ? S root 15 0.0 0.0 0 0 ? S root 20 0.0 0.0 0 0 ? S root 21 0.0 0.0 0 0 ? S root 22 0.0 0.0 0 0 ? S root 90 0.0 0.0 0 0 ? S root 91 0.0 0.0 0 0 ? S root 94 0.0 0.0 0 0 ? S root 96 0.0 0.0 0 0 ? S root 168 0.0 0.0 0 0 ? S Jul15 0:00 [khungtaskd]
root 169 0.0 0.0 0 0 ? S Jul15 0:00 [pdflush]
root 170 0.0 0.0 0 0 ? S Jul15 0:00 [pdflush]
root 171 0.0 0.0 0 0 ? S root 172 0.0 0.0 0 0 ? S root 173 0.0 0.0 0 0 ? S root 317 0.0 0.0 0 0 ? S root 361 0.0 0.0 0 0 ? S root 362 0.0 0.0 0 0 ? S root 363 0.0 0.0 0 0 ? S root 373 0.0 0.0 0 0 ? S root 386 0.0 0.0 0 0 ? S root 407 0.0 0.0 0 0 ? S root 435 0.0 0.1 12672 764 ? S root 1059 0.0 0.0 0 0 ? S root 1060 0.0 0.0 0 0 ? S root 1062 0.0 0.0 0 0 ? S root 1112 0.0 0.0 0 0 ? S root 1429 0.0 0.1 5908 608 ? Ss Jul15 0:00 syslogd -m 0
root 1432 0.0 0.0 3804 424 ? Ss Jul15 0:00 klogd -x
dbus 1492 0.0 0.1 21256 964 ? Ss Jul15 0:00 dbus-daemon —system
root 1501 0.0 0.1 3800 580 ? Ss Jul15 0:00 /usr/sbin/acpid
68 1509 0.0 0.7 30604 3660 ? Ss Jul15 0:00 hald
root 1510 0.0 0.2 21692 1056 ? S Jul15 0:00 hald-runner
68 1518 0.0 0.1 12324 844 ? S Jul15 0:00 hald-addon-acpi: listening on acpid socket /var/run/acpid.socket
68 1523 0.0 0.1 12324 848 ? S Jul15 0:00 hald-addon-keyboard: listening on /dev/input/event0
root 1532 0.1 0.1 10228 680 ? S Jul15 4:09 hald-addon-storage: polling /dev/hdc
root 1547 0.0 0.2 62624 1208 ? Ss Jul15 0:00 /usr/sbin/sshd
ntp 1558 0.0 0.9 23388 5028 ? SLs Jul15 0:00 ntpd -u ntp:ntp -p /var/run/ntpd.pid -g
root 1576 0.0 0.4 69004 2348 ? Ss Jul15 0:00 sendmail: accepting connections
smmsp 1584 0.0 0.3 59764 1800 ? Ss Jul15 0:00 sendmail: Queue runner@01:00:00 for /var/spool/clientmqueue
root 1593 0.0 0.2 19708 1144 ? Ss Jul15 0:00 crond
root 1601 0.0 0.0 18732 456 ? Ss Jul15 0:00 /usr/sbin/atd
root 1615 0.0 0.2 52108 1332 ? Ss Jul15 0:00 login — root
root 1616 0.0 0.0 3792 480 tty2 Ss+ Jul15 0:00 /sbin/mingetty tty2
root 1617 0.0 0.0 3792 484 tty3 Ss+ Jul15 0:00 /sbin/mingetty tty3
root 1628 0.0 0.0 3792 480 tty4 Ss+ Jul15 0:00 /sbin/mingetty tty4
root 1629 0.0 0.0 3792 480 tty5 Ss+ Jul15 0:00 /sbin/mingetty tty5
root 1640 0.0 0.0 3792 480 tty6 Ss+ Jul15 0:00 /sbin/mingetty tty6
root 1641 0.0 0.1 3800 536 ttyS0 Ss+ Jul15 0:00 /sbin/agetty -h 115200 ttyS0 vt100
root 1684 0.0 3.1 201952 15920 ? SN Jul15 0:00 /usr/bin/python -tt /usr/sbin/yum-updatesd
root 1686 0.0 0.2 12916 1160 ? SN Jul15 0:00 /usr/libexec/gam_server
root 1722 0.0 0.6 90320 3528 ? Ss Jul15 0:00 sshd: root@pts/0
root 1724 0.0 0.2 10932 1440 pts/0 Ss+ Jul15 0:00 -bash
root 1758 0.0 0.2 10928 1372 tty1 Ss+ Jul15 0:00 -bash
root 10606 0.0 0.6 91048 3380 ? Rs 13:17 0:00 sshd: root@pts/1
root 10608 0.0 0.2 10932 1392 pts/1 Ss 13:17 0:00 -bash
root 10643 0.0 0.1 10460 876 pts/1 R+ 13:38 0:00 ps -aux

まず、コンソール（mingetty）はこんなに要らないので、減らします。

/etc/inittabを以下のように編集

# Run gettys in standard runlevels
1:2345:respawn:/sbin/mingetty tty1
#2:2345:respawn:/sbin/mingetty tty2
#3:2345:respawn:/sbin/mingetty tty3
#4:2345:respawn:/sbin/mingetty tty4
#5:2345:respawn:/sbin/mingetty tty5
#6:2345:respawn:/sbin/mingetty tty6

デーモンも減らします。

[root@www10xxu ~]# chkconfig yum-updatesd off
[root@www10xxu ~]# chkconfig haldaemon off
[root@www10xxu ~]# chkconfig yum-updatesd off
[root@www10xxu ~]# chkconfig acpid off
[root@www10xxu ~]# chkconfig messagebus off

これで再起動すれば、ずいぶんとメモリの空きができます。
再起動後に確認すると、使用中は150MBとなっていました。もう少しがんばれば、もっと削減できそうです。

「さくらのVPS」を使ってみる (さくらインターネット創業日記)

swapが使えるLinuxKVMベースのVPSサービスの紹介です。OpenVZだとswapが無い為、定められたメモリ量を超える事は出来ません。一時的な負荷の上昇でswapoutも出来ません。
そういった所からLinuxKVMなVPSはとても貴重です。

1年前 | 固定リンク | 2010年 7月 31日 |

2010年 7月 29日

	m1.small	c1.medium	m1.large	m1.xlarge	c1.xlarge
Dhrystone 2 using register variables	318.2	839	958.8	961.4	1109
Double-Precision Whetstone	396.4	376.5	301.6	394.7	487.2
Execl Throughput	196.7	371.7	-	-	-
File Copy 1024 bufsize 2000 maxblocks	113.8	354.5	537.8	562.6	643.4
File Copy 256 bufsize 500 maxblocks	74.9	221.3	348.5	361.1	415.8
File Copy 4096 bufsize 8000 maxblocks	239.5	739.1	906	920.4	1101.7
Pipe Throughput	48	144.9	259	270.3	314.1
Pipe-based Context Switching	55	89.6	199.8	156.9	217
Process Creation	111.1	269.9	272.2	281.1	320
Shell Scripts (8 concurrent)	352.5	1076.5	1310.3	1637.7	1227.8
System Call Overhead	447.2	551	226.8	243.7	283.4

	m2.xlarge	m2.2xlarge	m2.4xlarge	cc1.4xlarge
Dhrystone 2 using register variables	1311.4	1313.4	1313	1438.6
Double-Precision Whetstone	549.9	550.5	550.8	604
Execl Throughput	-	-	-	-
File Copy 1024 bufsize 2000 maxblocks	749.2	743.5	741.4	1645.2
File Copy 256 bufsize 500 maxblocks	478.5	478.2	471.1	1049.4
File Copy 4096 bufsize 8000 maxblocks	1512.2	1513.5	1495.8	2694.7
Pipe Throughput	347.7	349.4	348.7	1059.8
Pipe-based Context Switching	313.7	298.1	318.3	-
Process Creation	377.6	377.5	375.7	225.3
Shell Scripts (8 concurrent)	1826.7	2551.7	2333.8	738.3
System Call Overhead	362.2	361.6	363.1	716.2

“cc1.4xlarge”は、計算処理もそうですが、ファイルコピーのパフォーマンスが素晴らしいですね。

あと、やはり、c1.medium(2.5ECU x 2)より、m1.large(2ECU x 2)の方が、CPUパワーが優れていそう(CPUの型番的には納得)なのと、m2.xlargeのI/Oパフォーマンスは”High”ではなかろうか？と思った次第。

Amazon EC2性能検証！気になるパフォーマンスをインスタンスタイプやリージョン毎に計測・比較してみた - RX-7乗りの適当な日々

m1.smallなどの対応は以下の通りです。
その他詳しい計測結果はリンク先をご参照ください。

＊Standard Instances
Small Instance [m1.small] (32-bit) (*Default)
Large Instance [m1.large] (64-bit)
Extra Large Instance [m1.xlarge] (64-bit)

＊High-CPU Instances
High-CPU Medium Instance [c1.medium] (64-bit)
High-CPU Extra Large Instance [c1.xlarge] (64-bit)

＊High-Memory Instances
High-Memory Extra Large Instance [m2.xlarge] (64-bit)
High-Memory Double Extra Large Instance [m2.2xlarge] (64-bit)
High-Memory Quadruple Extra Large Instance [m2.4xlarge] (64-bit)

＊Cluster Compute Instances
Cluster Compute Quadruple Extra Large Instance [cc1.4xlarge] (64-bit)

1年前 | 固定リンク | 2010年 7月 29日 |

2010年 7月 27日

pixivではDNSラウンドロビンを限界まで使ってみたことがあるという。ぶら下げるWebサーバの数が一定数を超えると「DNSレコードがUDPパ
ケットに収まらなくて、ユーザーの環境によっては“画像が見えない”ということが起こった」（店本氏）という。DNSでは応答が512バイトを超えると、
TCPにフォールバックしようとするが、家庭用ルータにはこの仕組みがうまく扱えないものもあるからだ。現在はデータセンター側にフロントサーバとして
20台のNginxを設置して、これにURL文字列のハッシュ値をベースとする負荷分散の仕組み「carp」のモジュールを入れて使っているという。必ずしも高
価なスイッチやロードバランサを入れなくても、億単位のページビューをさばけるという実例だ。

ベニヤ板とDCのハイブリッド！ pixivインフラの今 − ＠IT

DNSラウンドロビン、意外なところに落とし穴があるのですね。

1年前 | 固定リンク | 2010年 7月 27日 |

2010年 7月 27日

ルートサーバってなんだろうその２

27.05.10 / DNSって何？, 小ネタ / Author: aico / Comments: (0)

前回、ルートサーバは世界に１３個あり、日本では、その１つをWIDEプロジェクトが管理しているということがわかりました。

ルートサーバは名前空間の最も上に位置するサーバです。
なので、もし１３台すべてのルートサーバがアクセスできない状態になると、インターネットは使えなくなってしまいます。

２００２年、DDoS攻撃というルートサーバへの攻撃によって１３台のうち９台のルートサーバが影響をうけ、内７台は一時的にサービスが不能になった事件が起きました。

DNSではプロトコル上の制限によりルートサーバーとして指定可能なサーバーが最大13台までに制限されているため、通常の方法ではそれを超える数のサーバーを配置することはできません。

そこで、IP Anycastという、IPアドレスを複数のサーバで共有する技術によって、同じIPアドレスをもつDNSサーバーが世界各地に設置されました。IP Anycastでは、ユーザーはそのうち最も効率よくすばやく情報をおくってくれるサーバーに接続するようになっています。

なので、日本にもM.ROOT-SERVERS.NETの他に４つの海外の企業が管理するルートサーバと同じIPアドレスを持ったサーバが設置されています。

つまり、１３台というのは、ルートサーバの数ではなく、サーバを仕切るホストコンピュータの数なのです。

ルートサーバの管理するルートドメインはふだんドメイン名(FQDN)にかかれることはありません。しかし、このように管理されながら、インターネットの世界で重要な役割をはたしているのです！

小悪魔女子大生のサーバエンジニア日記

絵のタッチがとても素敵なインフラエンジニアの卵のブログです。

1年前 | 固定リンク | 2010年 7月 27日 |