雑談

ふなっしーのようにDMM非公認のブログのつもりだったのですが、

DMM社長に見つかってしまった。^^;

https://twitter.com/dmm_matsue

>松栄社長。

変な事ばらさないでくださいよー

glusterfs, 歴史

 

 

gazou_dai1

 

これは第一世代の構成です。

3階層モデルで設計されています。

あまりの画像の細かさにディスクIOをプロクシサーバをスケールアウトさせることで稼いでいる状態。

これでもトラフィックは1Gbpsくらいだったと記憶しています。

gazou_dai2

 

これが第2世代

サーバの台数を考えるとCDNを利用したほうが安かった。

さらに第一世代ではよくあったパフォーマンス不足問題も完全に解決。

ただし、キャッシュの保持期間に問題があり、タイムリーなキャッシュクリアに難があった。

gazou_cur

 

これが第三世代の構成です。

第二世代で問題となるキャッシュクリア問題を解決し、パフォーマンスの改善、さらにはコストも低下させたバージョン。

この構成で自社配信でもCDN配信でもどちらの配信も選択できるようなクラウドシステムとなった。

海外はCDN、国内は自社配信のように使い分ける。

GlusterFSについてはDistributed-Replicaを選択してデータを3重化しています。

ですので、すべてのサーバで同じコンテンツが保持されるようになっています。

ところで、やっぱりiodriveはすごい。

1台で数千万のファイルを7Gbpsで配信できます。※実績、たぶん楽勝で10Gbpsだせると思います。

iodriveがあまりに速度を出してしまうので、Emulexの10GNICで定期的にフリーズが発生するほどです。

これはすでに解決したのですが別の機会にお話ししますね。

また、GlusterFSは細かいファイルが苦手なのですが、このためファイルの同期にめちゃくちゃ時間がかかってしまう状態となります。これもちょっとした小技で解決済みです。これも別の機会にお話ししますね。

 

 

 

運用管理

iphone5

 

インフラチームにはフィールドエンジニア部門がありまして、

日々、サーバの納品対応、ラッキング、ケーブリング、ファームなどのバージョン管理、修理、コロケーションの備品管理などでiphone片手に飛び回っています。

インフラエンジニアとの連絡はiphoneを利用し、

メッセージの交換はimessageを使います。

みんなツチノコですのでfacetimeは使いません。

また、サーバの外観の写真や動画をリアルタイムに共有し、その場で対応を協議しています

また、youtubeへ動画をアップロードしメーカーへ提示することもあります。

さらに、iphoneのvpn機能を利用して社内のvpnサーバと接続、そのサーバ経由で内部の管理サーバへアクセスしたりもします。

携帯が原則ダメなiDCや電波が弱いiDCにはwifiルータを設置すれば事足ります。

ちなみに、RSA SecurIDのパスコードもiphoneで確認できるようになっています。

なぜiphoneなのか

ズバリ、キーパッドの入力精度の高さと電池の持ちです。

次期バージョンiphone5s?でAndroidと同じくらいの電力消費にならないことを祈ります。

みなさんの便利な使い方をコメントいただけるとうれしいです。

 

 

セキュリティ

古い記事で申し訳ないですが、

NIST により2013/5/14 に、 RHEL6.1 – 6.4 をはじめとする Linux ディストリビューションに、perf のバグをついて権限昇格される脆弱性があることがアナウンスされています。

Vulnerability Summary for CVE-2013-2094
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-209…

この深刻なバグにより、ユーザ権限でインターネットで公開されている、semtex.cというファイルをコンパイルし動作させることでrootを奪取することが可能です。semtex.cは今でも簡単に探せます

そもそも、ユーザ権限がないとroot奪取は出来ないのですが、

外部の方に対して開発や運用をお任せするために自社環境のユーザ権限をお渡ししている場合は念のため対応したほうが良いと思います。

RHEL5系は問題ありませんが、RHEL6系をお使いの場合は
カーネルのバージョンを2.6.32-358.6.2.el6.x86_64へアップデートすることで対策が可能とのことです。

アップデート例
# yum update kernel*
# reboot

もちろんScientificやCentOSの6系も対象です。

もし、のっぴきならない状況でkernelをアップデートしたくないって方は

公式ではないのですがperf_swevent_init()というファンクションを問題がでないようラッピングしてくれるカーネルモジュールが公開されています。

こちらが参考になるかと思います。

dmmではまだ5系が主流ですのでほとんど影響がないのですが、

テスト検証してみると、まあ、いとも簡単にrootが奪取できちゃいますね。

13年くらい前にtelnetのバッファオーバーフローにてリモートからrootが奪取できるバグを試して以来の衝撃「#」でした。

この時はログイン履歴もhistoryにも何も残らない状態でしたが、

今回のものはwでもlastでもhistoryも通常通り確認できていました。

 

運用管理

みなさん、機器管理のIDはどう管理されていますか?

dmmではsrv[4桁の数字]を使い、テプラで機器の前後に貼り付るようにしています。

ホスト名もこの名前になります。

機器番号は1度割り当てられると基本変更出来ないルールになっています。

人の名前と同じと考えればわかりやすいですかね。

また、運用にスピード感を持たせるためIPMIのIPアドレスと4桁の数字は連動させています。

つまり、機器番号が分かれば確認すべき機器が即座にわかりIPMI経由で素早く状況が確認できるようになっています。

例えば

機器番号がsrv1234ならば、管理用のIPアドレスは10.0.12.34/8とし、手動もしくはdhcpで取得されるように設定します。

例外1:srv1200の場合は例外として10.0.12.100/8とする。カウントを一つ上げる。

例外2:管理IPが複数となる場合は第4オクテットの150~200までを割り当てる。

例外3:第4オクテットの201~240まではプライベートアドレスとして各自自由にテストなどで利用しても良い。けっしてサービスで使ってはならない。

とにかく初動を早くするための一つの方法として実践しています。

なぜ機器番号は変更してはいけないのかといいますと。

筐体交換の時にシールを張り替える必要が出てくること。

それに伴って2台分のIPMIのIPアドレスにも変更が必要になること。

さらにさらに変更に伴って情報の更新が必要なこと。

このオペミスに繋がり易い上記3つを防ぐためとなります。

 

ちなみに、記憶は曖昧なのですが、

昔はすべてのサーバに星の名前をつけていました。

もちろん、すぐに破綻することになるんですけども、ただの番号になってしまうと悲しいかな愛着もへったくれもなくなってしまいます。^^;

愛着がでるよう別名も管理するといいかもしれない。

PAGE TOP